On Tue, 7 Apr 2020, Christopher Faylor wrote:
> >In a way that's amusing and just reinforces my p.o.v. that DMARC is
> >bollocks.
>
> Not that it means anything but I agree 100%.
>
> It's like whoever made the "standard" just said "to hell with mailing
> lists".
Maybe they just didn't know of
On Tue, 7 Apr 2020, Christopher Faylor wrote:
> >Can we please switch it off? It's not like we really had a problem before
> >the switch to mailman.
>
> You can't really make statements like this which imply that you are
> aware of "problems" on sourceware when you're not a sourceware
> adminis
On Tue, Apr 07, 2020 at 03:56:09PM +, Michael Matz wrote:
>In a way that's amusing and just reinforces my p.o.v. that DMARC is
>bollocks.
Not that it means anything but I agree 100%.
It's like whoever made the "standard" just said "to hell with mailing
lists".
On Tue, Apr 07, 2020 at 03:13:53PM +, Michael Matz wrote:
>Can we please switch it off? It's not like we really had a problem before
>the switch to mailman.
You can't really make statements like this which imply that you are
aware of "problems" on sourceware when you're not a sourceware
admi
Hello,
On Tue, 7 Apr 2020, Frank Ch. Eigler wrote:
> > I find that unconvincing, because even googlegroup email lists don't
> > mangle From: from sender domains that are now mangled by sourceware.org
> > :-/
>
> It turns out receiving mail FROM google-groups mail is itself
> sometimes at risk
Hi -
> > A number of lists I'm on switched to our current style of minging a
> > year or two ago, because gmail users were not receiving mail, because
> > gmail was rejecting the mail.
>
> I find that unconvincing, because even googlegroup email lists don't
> mangle From: from sender domains tha
Hello,
On Tue, 7 Apr 2020, Jonathan Wakely via Gcc wrote:
> On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc
> wrote:
> > And can certainly score a positive though not a definite rating in spam
> > qualification. I don't think we ought to encourage bad IT management
> > practices by try
On 4/7/20 4:09 PM, Frank Ch. Eigler wrote:
Hi -
There's update SVN to GIT map file:
https://drive.google.com/file/d/1DMuFDu476stLdMxKSaDzv4c81rhMAGEI/view?usp=sharing
Updated.
Thanks. I can form https://gcc.gnu.org/r12345 works right now.
Martin
- FChE
Hi -
> There's update SVN to GIT map file:
> https://drive.google.com/file/d/1DMuFDu476stLdMxKSaDzv4c81rhMAGEI/view?usp=sharing
Updated.
- FChE
On Tue, Apr 7, 2020 at 2:41 PM Erick Ochoa
wrote:
>
>
>
> On 07/04/2020 14:34, Michael Matz wrote:
> > Hello,
> >
> > On Tue, 7 Apr 2020, Erick Ochoa wrote:
> >
> >> Thanks for this lead! It is almost exactly what I need. I do have one more
> >> question about this. It seems that the types obtaine
Hello,
On Tue, 7 Apr 2020, Erick Ochoa wrote:
> > So, when you want to compare types use useless_type_conversion_p (for
> > equivalence you need useless(a,b) && useless(b,a)). In particular,
> > for record types T it's TYPE_CANONICAL(T) that needs to be
> > pointer-equal. (I.e. you could hard
On 07/04/2020 14:34, Michael Matz wrote:
Hello,
On Tue, 7 Apr 2020, Erick Ochoa wrote:
Thanks for this lead! It is almost exactly what I need. I do have one more
question about this. It seems that the types obtained via
FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when compil
Hello,
On Tue, 7 Apr 2020, Erick Ochoa wrote:
> Thanks for this lead! It is almost exactly what I need. I do have one more
> question about this. It seems that the types obtained via
> FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when compiled with
> -flto.
>
> What do I mean by t
On 4/7/20 2:01 PM, Erick Ochoa wrote:
Hello,
Can someone help me understand better GCC's profile driven instrumentation? I
know this can be a long topic, but I am not looking for a long discussion. I am
just trying to orient myself regarding GCC's FDO implementation.
Hello.
Sure.
1. I kn
On Tue, Apr 7, 2020 at 1:54 PM Erick Ochoa
wrote:
>
> Hello Micheal,
>
> Thanks for this lead! It is almost exactly what I need. I do have one
> more question about this. It seems that the types obtained via
> FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when
> compiled with -flto.
Hello,
Can someone help me understand better GCC's profile driven
instrumentation? I know this can be a long topic, but I am not looking
for a long discussion. I am just trying to orient myself regarding GCC's
FDO implementation.
1. I know that gcc uses an instrumentation based profiler. Thi
Hello Micheal,
Thanks for this lead! It is almost exactly what I need. I do have one
more question about this. It seems that the types obtained via
FOR_EACH_FUNCTION_ARGS and TREE_TYPE are different pointers when
compiled with -flto.
What do I mean by this? Consider the following code:
#inc
* Jonathan Wakely:
> On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc
> wrote:
>> And can certainly score a positive though not a definite rating in spam
>> qualification. I don't think we ought to encourage bad IT management
>> practices by trying to adapt to them too hard and hurting o
On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc wrote:
> And can certainly score a positive though not a definite rating in spam
> qualification. I don't think we ought to encourage bad IT management
> practices by trying to adapt to them too hard and hurting ourselves (our
> workflow) in
On 4/7/20 9:29 AM, Martin Liška wrote:
On 4/7/20 9:22 AM, Andreas Schwab wrote:
On Apr 07 2020, Martin Liška wrote:
Can you please help me how can one clone (or pull) complete content of git repo?
Easiest way is to do a mirror clone.
All right, --mirror is a new option to me.
There's upd
On 4/7/20 9:22 AM, Andreas Schwab wrote:
On Apr 07 2020, Martin Liška wrote:
Can you please help me how can one clone (or pull) complete content of git repo?
Easiest way is to do a mirror clone.
All right, --mirror is a new option to me.
Doing that.
Thanks,
Martin
Andreas.
On Apr 07 2020, Martin Liška wrote:
> Can you please help me how can one clone (or pull) complete content of git
> repo?
Easiest way is to do a mirror clone.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for
On 4/6/20 5:04 PM, Joseph Myers wrote:
On Mon, 6 Apr 2020, Andrew Pinski via Gcc wrote:
That is r105377 till r105390 was only ever done on a test SVN repo and
r105927 (hooks) was the first commit to SVN after the conversion from
Actually r105926 (creating the hooks directory) was the first co
23 matches
Mail list logo
