On Montag, 3. Februar 2020 21:47:13 CET Marek Polacek wrote:
> On Mon, Feb 03, 2020 at 09:26:40PM +0100, Allan Sandfeld Jensen wrote:
> > Hello gcc
> >
> > I have now twice hit obscure bugs in Chromium that crashed on some
> > compilers but not on others, and didn't produce any warnings on any
> >
On Mon, Feb 03, 2020 at 09:26:40PM +0100, Allan Sandfeld Jensen wrote:
> Hello gcc
>
> I have now twice hit obscure bugs in Chromium that crashed on some compilers
> but not on others, and didn't produce any warnings on any compiler. I would
> like to know if this code is as undefined as I think
Hello gcc
I have now twice hit obscure bugs in Chromium that crashed on some compilers
but not on others, and didn't produce any warnings on any compiler. I would
like to know if this code is as undefined as I think it is, and if it would
make sense to have gcc warn about it.
Both cases basica
On Mon, 2020-02-03 at 18:55 +, Richard Sandiford wrote:
> "H.J. Lu" writes:
> > On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote:
> > > On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
> > > > > > In my experience the output of git log is a total mess so cannot
> > > > > > replace Chan
On Mon, Feb 03, 2020 at 06:20:20PM +, Michael Matz wrote:
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> > Well, I'd review a patch differently depending on whether or not it was
> > already committed, a patch requiring review or an RFC looking for more
> > general comments, so I *do
On Mon, Feb 03, 2020 at 06:54:05PM +0100, Jakub Jelinek wrote:
> On Mon, Feb 03, 2020 at 05:48:57PM +, Michael Matz wrote:
> > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> >
> > > The idea is that the [...] part is NOT part of the commit, only part of
> > > the email.
> >
> > I unde
"H.J. Lu" writes:
> On Fri, Jan 24, 2020 at 2:39 PM Paul Smith wrote:
>>
>> On Fri, 2020-01-24 at 22:45 +0100, Jakub Jelinek wrote:
>> > > > In my experience the output of git log is a total mess so cannot
>> > > > replace ChangeLogs. But we can well decide to drop ChangeLog for
>> > > > the tes
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Well, I'd review a patch differently depending on whether or not it was
> already committed, a patch requiring review or an RFC looking for more
> general comments, so I *do* think such an email prefix is useful.
As I said: a very go
Hello,
On Mon, 3 Feb 2020, Jakub Jelinek wrote:
> > > The idea is that the [...] part is NOT part of the commit, only part of
> > > the email.
> >
> > I understand that, but the subject line of this thread says "e-mail
> > subject lines", so I thought we were talking about, well, exactly that;
Thanks for the answer, and sorry for slow follow-up. Got distracted by
other things...
Jeff Law writes:
> On Sat, 2020-01-25 at 09:31 +, Richard Sandiford wrote:
>> TL;DR: if we have two bare SYMBOL_REFs X and Y, neither of which have an
>> associated source-level decl and neither of which a
On Mon, 3 Feb 2020, Michael Matz wrote:
> I understand that, but the subject line of this thread says "e-mail
> subject lines", so I thought we were talking about, well, exactly that;
> and I see no value of these tags in e-mails either.
I agree that [PATCH] is not useful (and in general, anyth
On 03/02/2020 17:48, Michael Matz wrote:
Hi,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
The idea is that the [...] part is NOT part of the commit, only part of
the email.
I understand that, but the subject line of this thread says "e-mail
subject lines", so I thought we were talking
On Mon, Feb 03, 2020 at 05:48:57PM +, Michael Matz wrote:
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
>
> > The idea is that the [...] part is NOT part of the commit, only part of
> > the email.
>
> I understand that, but the subject line of this thread says "e-mail
> subject line
Hi,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> The idea is that the [...] part is NOT part of the commit, only part of
> the email.
I understand that, but the subject line of this thread says "e-mail
subject lines", so I thought we were talking about, well, exactly that;
and I see
On 03/02/2020 17:31, Michael Matz wrote:
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
Where does your '50 chars' limit come from? It's not in the glibc text,
and it's not in the linux kernel text either. AFAICT this is your
invention and you seem to be the only person proposing
On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote:
> I think the linux rule (the whole line, not including the parts that are
> removed on commit, should not exceed 75 characters) is far more sensible
> - which is why this draft states this.
FWIW, on a slightly older kerne
Hello,
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Where does your '50 chars' limit come from? It's not in the glibc text,
> and it's not in the linux kernel text either. AFAICT this is your
> invention and you seem to be the only person proposing it.
Nope, it's fairly common, so m
On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote:
> On 03/02/2020 13:54, Segher Boessenkool wrote:
> >None of this are *rules*. We should not pretend they are. An email
> >subject should be useful to what the receivers of that email use it for:
> >see if it very interestin
On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote:
> On 03/02/2020 13:54, Segher Boessenkool wrote:
> >None of this are *rules*. We should not pretend they are. An email
> >subject should be useful to what the receivers of that email use it for:
> >see if it very interestin
On Mon, 3 Feb 2020 15:04:57 +
"Richard Earnshaw (lists)" wrote:
> On 03/02/2020 14:13, Jonathan Wakely wrote:
> > On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote:
> >> Where does your '50 chars' limit come from? It's not in the glibc text,
> >> and it's not in the linux kernel
On 03/02/2020 15:13, Richard Earnshaw (lists) wrote:
On 03/02/2020 14:10, Jason Merrill wrote:
On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov
wrote:
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
Upper case is what glibc has, though it appears that it's a rule
that is
not
strictly
On 03/02/2020 14:10, Jason Merrill wrote:
On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote:
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
Upper case is what glibc has, though it appears that it's a rule that is
not
strictly followed. If we change it, then it becomes another fr
On 03/02/2020 14:13, Jonathan Wakely wrote:
On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote:
Where does your '50 chars' limit come from? It's not in the glibc text,
and it's not in the linux kernel text either. AFAICT this is your
invention and you seem to be the only person propos
On Mon, 3 Feb 2020 at 14:00, Richard Earnshaw (lists) wrote:
> Where does your '50 chars' limit come from? It's not in the glibc text,
> and it's not in the linux kernel text either. AFAICT this is your
> invention and you seem to be the only person proposing it.
It's a fairly well established c
On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote:
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
>
> > Upper case is what glibc has, though it appears that it's a rule that is
> not
> > strictly followed. If we change it, then it becomes another friction
> point
> > between develope
On 03/02/2020 13:54, Segher Boessenkool wrote:
On Mon, Feb 03, 2020 at 02:54:05PM +0300, Alexander Monakov wrote:
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
I've not seen any follow-up to this version. Should we go ahead and adopt
this?
Can we please go with 'committed' (lowercase)
On Mon, Feb 03, 2020 at 02:54:05PM +0300, Alexander Monakov wrote:
> On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
>
> > I've not seen any follow-up to this version. Should we go ahead and adopt
> > this?
>
> Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED?
> S
On 2/3/20 5:15 AM, Richard Earnshaw (lists) wrote:
On 25/01/2020 16:11, Jeff Law wrote:
On Sat, 2020-01-25 at 10:50 -0500, Nathan Sidwell wrote:
On 1/24/20 4:36 PM, Jeff Law wrote:
On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
I strongly prefer to move towards relying on the git log
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> Upper case is what glibc has, though it appears that it's a rule that is not
> strictly followed. If we change it, then it becomes another friction point
> between developer groups. Personally, I'd leave it as is, then turn a blind
> eye to s
On 03/02/2020 11:54, Alexander Monakov wrote:
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
I've not seen any follow-up to this version. Should we go ahead and adopt
this?
Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED?
Spelling this with all-caps seems li
On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote:
> I've not seen any follow-up to this version. Should we go ahead and adopt
> this?
Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED?
Spelling this with all-caps seems like a recent thing on gcc-patches, before
every
On 22/01/2020 17:45, Richard Earnshaw (lists) wrote:
[updated based on v2 discussions]
This patch proposes some new (additional) rules for email subject lines
when contributing to GCC. The goal is to make sure that, as far as
possible, the subject for a patch will form a good summary when the
On 25/01/2020 16:11, Jeff Law wrote:
On Sat, 2020-01-25 at 10:50 -0500, Nathan Sidwell wrote:
On 1/24/20 4:36 PM, Jeff Law wrote:
On Fri, 2020-01-24 at 20:32 +0100, Eric Botcazou wrote:
I strongly prefer to move towards relying on the git log.
In my experience the output of git log is a tota
33 matches
Mail list logo
