Commit messages and the move to git

Commit messages and the move to git

[Richard Earnshaw (lists)]

With the move to git fairly imminent now it would be nice if we could 
agree on a more git-friendly style of commit messages; and, ideally, 
start using them now so that the converted repository can benefit from this.

Some tools, particularly gitk or git log --oneline, can use one-line 
summaries from a commit's log message when listing commits.  It would be 
nice if we could start adopting a style that is compatible with this, so 
that in future commits are summarized in a useful way.  Unfortunately, 
some of our existing commits show no useful information with tools like 
this.

Eg.

git log --oneline
2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) 
2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
29f4f5f13b9 [C++ PATCH] cleanup check_field_decls
0f931fb75ae 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran 
allocatable/pointer arrays
377311a90fa 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
cc286dd8517 Daily bump.
8e87e30df8d Regenerate libstdc++ HTML docs
fad04d507e0 Add remaining changes from P1065R2 "constexpr INVOKE"
d5e4b5a17de Partial implementation of C++20 of <ranges> header
345d712f776 Test --help=common for full sentences
a737cc23c15     PR preprocessor/92296   * internal.h (struct 
def_pragma_macro): Add is_builtin bitfield. 
(_cpp_restore_special_builtin): Declare.        * init.c 
(_cpp_restore_special_builtin): New function.  * directives.c 
(do_pragma_push_macro): For NT_BUILTIN_MACRO     set is_builtin and 
don't try to grab definition.        (cpp_pop_definition): Use 
_cpp_restore_special_builtin to restore       builtin macros.
e9c843f92f6 2019-10-31  Jozef Lawrynowicz  <jozef.l@mittosystems.com>
d7069e154ee [AArch64] Fix g++.target/aarch64/sve/vcond_1_run.C
ae5f034c085 [AArch64] Split gcc.target/aarch64/sve/vcond_4*

As you can see, some of these are useful and give a good summary of the 
patch, others only tell me who committed the patch, which is less than 
useful.  In other cases almost the entire ChangeLog entry gets printed 
because there is no blank line to tell git where the end of the summary 
lies.

The normal convention in git is that the one line summary is essentially 
the subject line of the email message that describes the patch and is 
then followed by a blank line before the body of the commit message.

R.

Re: Commit messages and the move to git

[Arnaud Charlet]

> With the move to git fairly imminent now it would be nice if we
> could agree on a more git-friendly style of commit messages; and,
> ideally, start using them now so that the converted repository can
> benefit from this.
> 
> Some tools, particularly gitk or git log --oneline, can use one-line
> summaries from a commit's log message when listing commits.  It
> would be nice if we could start adopting a style that is compatible
> with this, so that in future commits are summarized in a useful way.
> Unfortunately, some of our existing commits show no useful
> information with tools like this.

Strongly seconded. FWIW we've done that for a while in the gcc/ada directory
already since we're using GIT internally on GCC and GNAT sources.

Arno

Re: Commit messages and the move to git

[Martin Jambor]

On Mon, Nov 04 2019, Richard Earnshaw (lists) wrote:
> Some tools, particularly gitk or git log --oneline, can use one-line 
> summaries from a commit's log message when listing commits.  It would be 
> nice if we could start adopting a style that is compatible with this, so 
> that in future commits are summarized in a useful way.

...

> The normal convention in git is that the one line summary is essentially 
> the subject line of the email message that describes the patch and is 
> then followed by a blank line before the body of the commit message.
>

I wholeheartedly agree.  Thanks to everyone already doing this and
everyone else, please just start, adding a summary line takes just
minimal effort.

Martin

Re: Commit messages and the move to git

[Jeff Law]

On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote:
> With the move to git fairly imminent now it would be nice if we could
> agree on a more git-friendly style of commit messages; and, ideally,
> start using them now so that the converted repository can benefit from
> this.
> 
> Some tools, particularly gitk or git log --oneline, can use one-line
> summaries from a commit's log message when listing commits.  It would be
> nice if we could start adopting a style that is compatible with this, so
> that in future commits are summarized in a useful way.  Unfortunately,
> some of our existing commits show no useful information with tools like
> this.
I'd suggest we sync policy with glibc.  They're further along on the
ChangeLog issues.  Whatever they do in this space we should follow --
aren't we going to be using some of their hooks/scripts?

jeff

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 04/11/2019 16:04, Jeff Law wrote:
> On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote:
>> With the move to git fairly imminent now it would be nice if we could
>> agree on a more git-friendly style of commit messages; and, ideally,
>> start using them now so that the converted repository can benefit from
>> this.
>>
>> Some tools, particularly gitk or git log --oneline, can use one-line
>> summaries from a commit's log message when listing commits.  It would be
>> nice if we could start adopting a style that is compatible with this, so
>> that in future commits are summarized in a useful way.  Unfortunately,
>> some of our existing commits show no useful information with tools like
>> this.
> I'd suggest we sync policy with glibc.  They're further along on the
> ChangeLog issues.  Whatever they do in this space we should follow --
> aren't we going to be using some of their hooks/scripts?
> 
> jeff
> 

I wouldn't object to that.  But then, it's largely what I'm asking for, 
with a few minor details.

https://sourceware.org/glibc/wiki/Contribution%20checklist#Contribution_Email_Subject_Line

Seems to set out the rules.

I think we'd probably want to keep PRnnnnn rather than switch to BZ 
#nnnnnn, but otherwise there's nothing I'd object to.

It looks like, from a quick look at 
https://sourceware.org/ml/glibc-cvs/2019-q4/ that the email subject 
lines are largely what is used for the summary commits.

R.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Mon, 4 Nov 2019 at 10:29, Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> With the move to git fairly imminent now it would be nice if we could
> agree on a more git-friendly style of commit messages; and, ideally,
> start using them now so that the converted repository can benefit from this.
>
> Some tools, particularly gitk or git log --oneline, can use one-line
> summaries from a commit's log message when listing commits.  It would be
> nice if we could start adopting a style that is compatible with this, so
> that in future commits are summarized in a useful way.  Unfortunately,
> some of our existing commits show no useful information with tools like
> this.
>
> Eg.
>
> git log --oneline
> 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
> 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
> 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls
> 0f931fb75ae 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
> e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran
> allocatable/pointer arrays
> 377311a90fa 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
> cc286dd8517 Daily bump.
> 8e87e30df8d Regenerate libstdc++ HTML docs
> fad04d507e0 Add remaining changes from P1065R2 "constexpr INVOKE"
> d5e4b5a17de Partial implementation of C++20 of <ranges> header
> 345d712f776 Test --help=common for full sentences
> a737cc23c15     PR preprocessor/92296   * internal.h (struct
> def_pragma_macro): Add is_builtin bitfield.
> (_cpp_restore_special_builtin): Declare.        * init.c
> (_cpp_restore_special_builtin): New function.  * directives.c
> (do_pragma_push_macro): For NT_BUILTIN_MACRO     set is_builtin and
> don't try to grab definition.        (cpp_pop_definition): Use
> _cpp_restore_special_builtin to restore       builtin macros.
> e9c843f92f6 2019-10-31  Jozef Lawrynowicz  <jozef.l@mittosystems.com>
> d7069e154ee [AArch64] Fix g++.target/aarch64/sve/vcond_1_run.C
> ae5f034c085 [AArch64] Split gcc.target/aarch64/sve/vcond_4*
>
> As you can see, some of these are useful and give a good summary of the
> patch, others only tell me who committed the patch, which is less than
> useful.  In other cases almost the entire ChangeLog entry gets printed
> because there is no blank line to tell git where the end of the summary
> lies.
>
> The normal convention in git is that the one line summary is essentially
> the subject line of the email message that describes the patch and is
> then followed by a blank line before the body of the commit message.

I've already proposed a more specific format for libstdc++:
https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 04/11/2019 16:19, Jonathan Wakely wrote:
> On Mon, 4 Nov 2019 at 10:29, Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
>>
>> With the move to git fairly imminent now it would be nice if we could
>> agree on a more git-friendly style of commit messages; and, ideally,
>> start using them now so that the converted repository can benefit from this.
>>
>> Some tools, particularly gitk or git log --oneline, can use one-line
>> summaries from a commit's log message when listing commits.  It would be
>> nice if we could start adopting a style that is compatible with this, so
>> that in future commits are summarized in a useful way.  Unfortunately,
>> some of our existing commits show no useful information with tools like
>> this.
>>
>> Eg.
>>
>> git log --oneline
>> 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD)
>> 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
>> 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls
>> 0f931fb75ae 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
>> e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran
>> allocatable/pointer arrays
>> 377311a90fa 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
>> cc286dd8517 Daily bump.
>> 8e87e30df8d Regenerate libstdc++ HTML docs
>> fad04d507e0 Add remaining changes from P1065R2 "constexpr INVOKE"
>> d5e4b5a17de Partial implementation of C++20 of <ranges> header
>> 345d712f776 Test --help=common for full sentences
>> a737cc23c15     PR preprocessor/92296   * internal.h (struct
>> def_pragma_macro): Add is_builtin bitfield.
>> (_cpp_restore_special_builtin): Declare.        * init.c
>> (_cpp_restore_special_builtin): New function.  * directives.c
>> (do_pragma_push_macro): For NT_BUILTIN_MACRO     set is_builtin and
>> don't try to grab definition.        (cpp_pop_definition): Use
>> _cpp_restore_special_builtin to restore       builtin macros.
>> e9c843f92f6 2019-10-31  Jozef Lawrynowicz  <jozef.l@mittosystems.com>
>> d7069e154ee [AArch64] Fix g++.target/aarch64/sve/vcond_1_run.C
>> ae5f034c085 [AArch64] Split gcc.target/aarch64/sve/vcond_4*
>>
>> As you can see, some of these are useful and give a good summary of the
>> patch, others only tell me who committed the patch, which is less than
>> useful.  In other cases almost the entire ChangeLog entry gets printed
>> because there is no blank line to tell git where the end of the summary
>> lies.
>>
>> The normal convention in git is that the one line summary is essentially
>> the subject line of the email message that describes the patch and is
>> then followed by a blank line before the body of the commit message.
> 
> I've already proposed a more specific format for libstdc++:
> https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
> 

Well having additional requirements for a component on top of 'global' 
requirements doesn't pose a real problem as long as the maintainers of 
that component concur.

Having incompatible requirements would be problematic, though.

R.

Re: Commit messages and the move to git

[Segher Boessenkool]

On Mon, Nov 04, 2019 at 04:19:25PM +0000, Jonathan Wakely wrote:
> I've already proposed a more specific format for libstdc++:
> https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html

PR libstdc++/12345 takes up the first 19 chars of the short subject,
adding no useful information (unless the reader knows all PRs by heart,
you need to look it up to know what it is).

I usually put (PR12345) at the end of the subject.  The area is clear
from the rest of the subject already.


Segher

Re: Commit messages and the move to git

[Joseph Myers]

On Mon, 4 Nov 2019, Segher Boessenkool wrote:

> On Mon, Nov 04, 2019 at 04:19:25PM +0000, Jonathan Wakely wrote:
> > I've already proposed a more specific format for libstdc++:
> > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
> 
> PR libstdc++/12345 takes up the first 19 chars of the short subject,
> adding no useful information (unless the reader knows all PRs by heart,
> you need to look it up to know what it is).
> 
> I usually put (PR12345) at the end of the subject.  The area is clear
> from the rest of the subject already.

Agreed.  (Hint to patch submitters: if the subject line of your patch 
submission is just "Fix PR12345" or similar, people are less likely to 
review your patch because nothing about the subject tells anyone that the 
patch is in their area and so something they should pay attention to.  
Patch submissions need to have subjects that make clear very quickly what 
the patch is about.  This is also why I don't care for [PATCH] tags at the 
start of subject lines - they take away space for saying what the patch is 
about, and on gcc-patches we can expect things are patches, [PATCH] 
doesn't add useful information.)

I've been using git-style commit messages in GCC for the past five years.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Segher Boessenkool]

On Mon, Nov 04, 2019 at 01:43:17PM +0100, Martin Jambor wrote:
> On Mon, Nov 04 2019, Richard Earnshaw (lists) wrote:
> > Some tools, particularly gitk or git log --oneline, can use one-line 
> > summaries from a commit's log message when listing commits.  It would be 
> > nice if we could start adopting a style that is compatible with this, so 
> > that in future commits are summarized in a useful way.
> 
> ...
> 
> > The normal convention in git is that the one line summary is essentially 
> > the subject line of the email message that describes the patch and is 
> > then followed by a blank line before the body of the commit message.
> >
> 
> I wholeheartedly agree.  Thanks to everyone already doing this and
> everyone else, please just start, adding a summary line takes just
> minimal effort.

Making a good subject is work and takes time, just like making a good
commit message, just like making a good patch.

The effort is worth it for at least two reasons:

1) More people read the commit message than write it, and this balance
shifts much further towards "read" if you consider the commit history
instead of just the patch submissions.

2) Being forced to describe your patches often makes you find problems
with them, or more generally, can make you actually understand what you
are doing ;-)


Segher

Re: Commit messages and the move to git

[Segher Boessenkool]

On Mon, Nov 04, 2019 at 05:42:47PM +0000, Joseph Myers wrote:
> This is also why I don't care for [PATCH] tags at the 
> start of subject lines - they take away space for saying what the patch is 
> about, and on gcc-patches we can expect things are patches, [PATCH] 
> doesn't add useful information.)

Yeah, but various tools automatically add them (and v2 and 1/4 etc. tags,
which are extremely useful), so it would be very inconvenient to outlaw
them.  Oh, and it is what all of the rest of the world uses, I don't even
consciously *see* the standard stuff anymore, it's only when people get
creative ;-)


Segher

Re: Commit messages and the move to git

[Kewen.Lin]

Hi,

on 2019/11/4 下午6:29, Richard Earnshaw (lists) wrote:
> With the move to git fairly imminent now it would be nice if we could agree on a more git-friendly style of commit messages; and, ideally, start using them now so that the converted repository can benefit from this.
> 
> Some tools, particularly gitk or git log --oneline, can use one-line summaries from a commit's log message when listing commits.  It would be nice if we could start adopting a style that is compatible with this, so that in future commits are summarized in a useful way.  Unfortunately, some of our existing commits show no useful information with tools like this.
> 
> Eg.
> 
> git log --oneline
> 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
> 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls
> 0f931fb75ae 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
> e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran allocatable/pointer arrays
> 377311a90fa 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>

Sorry for the awful commit messages and thanks a lot for raising this up to stop me from stumbling continuously.

I just updated all my svn commit comments by "svn propedit svn:log --revprop -r N --editor-cmd vim",
but I guess it won't help any more if the upcoming git repo will come from some existing mirror?


BR,
Kewen

Re: Commit messages and the move to git

[Jonathan Wakely]

On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
>
> On Mon, 4 Nov 2019, Segher Boessenkool wrote:
>
> > On Mon, Nov 04, 2019 at 04:19:25PM +0000, Jonathan Wakely wrote:
> > > I've already proposed a more specific format for libstdc++:
> > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
> >
> > PR libstdc++/12345 takes up the first 19 chars of the short subject,
> > adding no useful information (unless the reader knows all PRs by heart,
> > you need to look it up to know what it is).
> >
> > I usually put (PR12345) at the end of the subject.  The area is clear
> > from the rest of the subject already.
>
> Agreed.  (Hint to patch submitters: if the subject line of your patch
> submission is just "Fix PR12345" or similar, people are less likely to
> review your patch because nothing about the subject tells anyone that the
> patch is in their area and so something they should pay attention to.
> Patch submissions need to have subjects that make clear very quickly what
> the patch is about.  This is also why I don't care for [PATCH] tags at the
> start of subject lines - they take away space for saying what the patch is
> about, and on gcc-patches we can expect things are patches, [PATCH]
> doesn't add useful information.)

I don't mind [PATCH] in the subject of patch emails (maybe because
nearly all my patches go to libstdc++@ as well, and not all mails on
that list are patches), but it has negative value in the commit log.

My mail to the libstdc++ list should have noted that [PATCH] tags in
the email subject should be omitted from the summary in the first line
of the commit log.


> I've been using git-style commit messages in GCC for the past five years.

I think I only started four years ago :-)

Re: Commit messages and the move to git

[Jason Merrill]

On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
> > On Mon, 4 Nov 2019, Segher Boessenkool wrote:
> >
> > > On Mon, Nov 04, 2019 at 04:19:25PM +0000, Jonathan Wakely wrote:
> > > > I've already proposed a more specific format for libstdc++:
> > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
> > >
> > > PR libstdc++/12345 takes up the first 19 chars of the short subject,
> > > adding no useful information (unless the reader knows all PRs by heart,
> > > you need to look it up to know what it is).
> > >
> > > I usually put (PR12345) at the end of the subject.  The area is clear
> > > from the rest of the subject already.
> >
> > Agreed.  (Hint to patch submitters: if the subject line of your patch
> > submission is just "Fix PR12345" or similar, people are less likely to
> > review your patch because nothing about the subject tells anyone that the
> > patch is in their area and so something they should pay attention to.
> > Patch submissions need to have subjects that make clear very quickly what
> > the patch is about.  This is also why I don't care for [PATCH] tags at the
> > start of subject lines - they take away space for saying what the patch is
> > about, and on gcc-patches we can expect things are patches, [PATCH]
> > doesn't add useful information.)
>
> I don't mind [PATCH] in the subject of patch emails (maybe because
> nearly all my patches go to libstdc++@ as well, and not all mails on
> that list are patches), but it has negative value in the commit log.

I actively like [PATCH] in the subject line because I see patch mail
interleaved with other mail in my inbox.

> My mail to the libstdc++ list should have noted that [PATCH] tags in
> the email subject should be omitted from the summary in the first line
> of the commit log.

And git format-patch/git am automatically add and remove [PATCH] appropriately.

I tend to put the PR number at the beginning of the line, but I don't
object to putting it at the end instead.

Jason

Re: Commit messages and the move to git

[Marek Polacek]

On Tue, Nov 05, 2019 at 11:27:50AM +0000, Jason Merrill wrote:
> On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
> > > On Mon, 4 Nov 2019, Segher Boessenkool wrote:
> > >
> > > > On Mon, Nov 04, 2019 at 04:19:25PM +0000, Jonathan Wakely wrote:
> > > > > I've already proposed a more specific format for libstdc++:
> > > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
> > > >
> > > > PR libstdc++/12345 takes up the first 19 chars of the short subject,
> > > > adding no useful information (unless the reader knows all PRs by heart,
> > > > you need to look it up to know what it is).
> > > >
> > > > I usually put (PR12345) at the end of the subject.  The area is clear
> > > > from the rest of the subject already.
> > >
> > > Agreed.  (Hint to patch submitters: if the subject line of your patch
> > > submission is just "Fix PR12345" or similar, people are less likely to
> > > review your patch because nothing about the subject tells anyone that the
> > > patch is in their area and so something they should pay attention to.
> > > Patch submissions need to have subjects that make clear very quickly what
> > > the patch is about.  This is also why I don't care for [PATCH] tags at the
> > > start of subject lines - they take away space for saying what the patch is
> > > about, and on gcc-patches we can expect things are patches, [PATCH]
> > > doesn't add useful information.)
> >
> > I don't mind [PATCH] in the subject of patch emails (maybe because
> > nearly all my patches go to libstdc++@ as well, and not all mails on
> > that list are patches), but it has negative value in the commit log.
> 
> I actively like [PATCH] in the subject line because I see patch mail
> interleaved with other mail in my inbox.
> 
> > My mail to the libstdc++ list should have noted that [PATCH] tags in
> > the email subject should be omitted from the summary in the first line
> > of the commit log.
> 
> And git format-patch/git am automatically add and remove [PATCH] appropriately.

Wrt [PATCH]: if we keep it, do we want to have a system to distinguish
C/C++/... patches?  Do we want [C++ PATCH] or [PATCH][C++] or [C++][PATCH],
something else?  (I find the latter two a bit ugly.)

Marek

Re: Commit messages and the move to git

[David Malcolm]

On Tue, 2019-11-05 at 11:27 +0000, Jason Merrill wrote:
> On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely <
> jwakely.gcc@gmail.com> wrote:
> > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
> > > On Mon, 4 Nov 2019, Segher Boessenkool wrote:
> > > 
> > > > On Mon, Nov 04, 2019 at 04:19:25PM +0000, Jonathan Wakely
> > > > wrote:
> > > > > I've already proposed a more specific format for libstdc++:
> > > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
> > > > 
> > > > PR libstdc++/12345 takes up the first 19 chars of the short
> > > > subject,
> > > > adding no useful information (unless the reader knows all PRs
> > > > by heart,
> > > > you need to look it up to know what it is).
> > > > 
> > > > I usually put (PR12345) at the end of the subject.  The area is
> > > > clear
> > > > from the rest of the subject already.
> > > 
> > > Agreed.  (Hint to patch submitters: if the subject line of your
> > > patch
> > > submission is just "Fix PR12345" or similar, people are less
> > > likely to
> > > review your patch because nothing about the subject tells anyone
> > > that the
> > > patch is in their area and so something they should pay attention
> > > to.
> > > Patch submissions need to have subjects that make clear very
> > > quickly what
> > > the patch is about.  This is also why I don't care for [PATCH]
> > > tags at the
> > > start of subject lines - they take away space for saying what the
> > > patch is
> > > about, and on gcc-patches we can expect things are patches,
> > > [PATCH]
> > > doesn't add useful information.)
> > 
> > I don't mind [PATCH] in the subject of patch emails (maybe because
> > nearly all my patches go to libstdc++@ as well, and not all mails
> > on
> > that list are patches), but it has negative value in the commit
> > log.
> 
> I actively like [PATCH] in the subject line because I see patch mail
> interleaved with other mail in my inbox.

FWIW my convention has been to put "[PATCH]" in the email subject line
for patches I want reviewed, and "[committed]" for patches that I've
already self-approved (or are obvious) and thus don't need review.

+1 from me on making commit messages have git-friendly summary lines
(I've been doing this myself since shortly after I joined gcc).

I'm not too bothered about the precise format FWIW - maybe it's better
not to be too prescriptive about the format, beyond "make them concise,
and useful for you and your fellow maintainers"?   I try to use the
same message as the email subject line, to make cross-referencing
between the mailing list and source repos easier when doing
"archaeology".

(that said, keeping "[PATCH]" in the *commit* message is a pet peeve of
mine, as it's redundant).

I also tend to put in the "blurb" from the email into the commit
message, especially if it's a pertinent high-level description of the
purpose of the *change* (as opposed to a description of the *code*,
which should live in a comment in the code, rather than the metadata).

> > My mail to the libstdc++ list should have noted that [PATCH] tags
> > in
> > the email subject should be omitted from the summary in the first
> > line
> > of the commit log.
> 
> And git format-patch/git am automatically add and remove [PATCH]
> appropriately.
> 
> I tend to put the PR number at the beginning of the line, but I don't
> object to putting it at the end instead.
> 
> Jason
> 

Re: Commit messages and the move to git

[Richard Earnshaw]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On 04/11/2019 16:04, Jeff Law wrote:
> On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote:
>> With the move to git fairly imminent now it would be nice if we could
>> agree on a more git-friendly style of commit messages; and, ideally,
>> start using them now so that the converted repository can benefit from
>> this.
>
> I'd suggest we sync policy with glibc.  They're further along on the
> ChangeLog issues.  Whatever they do in this space we should follow --
> aren't we going to be using some of their hooks/scripts?
> 
> jeff
> 


OK, based on these discussions here's an initial proposal for some 
wording in contribute.html for the web site.  I've based it strongly on 
the libc version, mostly with some restructuring and a tweak around bug 
numbers.

R.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emails.patch --]
[-- Type: text/x-patch; name="emails.patch", Size: 3821 bytes --]

diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index 80ebb26f..8f5741e5 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -261,6 +261,89 @@ that ChangeLog entries may be included as part of the patch and diffs
 representing new files may be omitted, especially if large, since they
 can be accessed directly from the repository.)</p> 
 
+<h3>Email subject lines</h3>
+
+Your contribution email subject line will become the first line of the
+commit message for your patch.
+
+A high-quality email subject line for a contribution contains the
+following elements:
+
+<ul>
+  <li>A classifier</li>
+  <li>Component tags</li>
+  <li>An optional series identifier</li>
+  <li>A brief summary</li>
+  <li>An optional bug number</li>
+</ul>
+
+<h4>Classifier</h4>
+
+The classifier identifies the type of contribution, for example a
+patch, an RFC (request for comments) or a committed patch (where
+approval is not necessary.  The classifier should be written in upper
+case and surrounded with square brackets.  This is the only component
+of the email subject line that will not appear in the commit itself.
+The classifier may optionally contain a version number (v<i>N</i>) and
+a series marker (<i>N/M</i>).  Examples are:
+
+<ul>
+  <li><code>[PATCH]</code> - a single patch</li>
+  <li><code>[PATCH v2]</code> - the second version of a single patch</li>
+  <li><code>[PATCH 3/7]</code> - the third patch in a series of seven
+    patches</li>
+  <li><code>[RFC]</code> - a point of discussion, may contain a patch</li>
+  <li><code>[COMMITTED]</code> - a patch that has already been committed.</li>
+</ul>
+
+<h4>Component tags</h4>
+
+A component tag is a short identifier that identifies the part of the
+compiler being modified, this is important as it highlights to
+relevant maintainers that the patch may need their attention.
+Multiple components may be listed if necessary.  Each component tag
+should be followed by a colon.  For example,
+
+<ul>
+  <li><code>vax: testsuite:</code></li>
+  <li><code>libstdc++:</code></li>
+  <li><code>combine:</code></li>
+</ul>
+
+<h4>Series identifier</h4>
+
+The series identifier is optional and is only relevant if a number of
+patches are needed in order to effect an overall change.  It should be
+a <i>short</i> string that identifies the series (it is common to all
+patches) and should be followed by a single dash surrounded by white
+space.
+
+<h4>Brief summary</h4>
+
+The brief summary encapsulates in a few words the intent of the
+change.  For example: <code>cleanup check_field_decls</code>.
+
+<h4>Bug number</h4>
+
+If your patch fixes a bug in the compiler for which there is an
+existing PR number the bug number should be stated.  Use the
+short-form variant (PR<i>nnnnn</i>) without the bugzilla component
+identifier.
+
+<h4>Other messages</h4>
+
+Some large patch sets benefit from an introductory email that provides
+more context for the patch series and describes how the patches have
+been broken up to provide for review.  The convention is that such
+messages should follow the same format as described above, but the
+patch number should be set to zero, for example: <code>[PATCH
+0/7]</code>.  Remember that the introductory message will not be
+committed with the patches themselves, so it should not contain any
+important information that is not also covered in the individual
+patches.  If you send a summary email with a series it is a good idea
+to send the patches as follow-ups (essentially replies) to your
+initial message so that mail software can group the messages together.
+
 <h3>Pinging patches, Getting patches applied</h3>
 
 <p>If you do not receive a response to a patch that you have submitted

Re: Commit messages and the move to git

[Segher Boessenkool]

On Tue, Nov 05, 2019 at 11:07:05AM +0000, Jonathan Wakely wrote:
> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
> > I've been using git-style commit messages in GCC for the past five years.
> 
> I think I only started four years ago :-)

I am        r210190   Wed May 7 22:00:58 2014 +0000
Joseph is   r214526   Tue Aug 26 17:06:31 2014 +0000
You are     r218698   Sat Dec 13 20:44:06 2014 +0000

Anyone else playing?  ;-)


Segher

Re: Commit messages and the move to git

[Iain Sandoe]

Segher Boessenkool <segher@kernel.crashing.org> wrote:

> On Tue, Nov 05, 2019 at 11:07:05AM +0000, Jonathan Wakely wrote:
>> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
>>> I've been using git-style commit messages in GCC for the past five years.
>> 
>> I think I only started four years ago :-)
> 
> I am        r210190   Wed May 7 22:00:58 2014 +0000
> Joseph is   r214526   Tue Aug 26 17:06:31 2014 +0000
> You are     r218698   Sat Dec 13 20:44:06 2014 +0000
> 
> Anyone else playing?  ;-)

I am - but probably for much less time than the others …

I think I started around the time Joseph observed it would be
a good idea to make the eventual commit messages nicer.

Iain

> 
> 
> Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 05/11/2019 14:12, Marek Polacek wrote:
> On Tue, Nov 05, 2019 at 11:27:50AM +0000, Jason Merrill wrote:
>> On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
>>>> On Mon, 4 Nov 2019, Segher Boessenkool wrote:
>>>>
>>>>> On Mon, Nov 04, 2019 at 04:19:25PM +0000, Jonathan Wakely wrote:
>>>>>> I've already proposed a more specific format for libstdc++:
>>>>>> https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
>>>>>
>>>>> PR libstdc++/12345 takes up the first 19 chars of the short subject,
>>>>> adding no useful information (unless the reader knows all PRs by heart,
>>>>> you need to look it up to know what it is).
>>>>>
>>>>> I usually put (PR12345) at the end of the subject.  The area is clear
>>>>> from the rest of the subject already.
>>>>
>>>> Agreed.  (Hint to patch submitters: if the subject line of your patch
>>>> submission is just "Fix PR12345" or similar, people are less likely to
>>>> review your patch because nothing about the subject tells anyone that the
>>>> patch is in their area and so something they should pay attention to.
>>>> Patch submissions need to have subjects that make clear very quickly what
>>>> the patch is about.  This is also why I don't care for [PATCH] tags at the
>>>> start of subject lines - they take away space for saying what the patch is
>>>> about, and on gcc-patches we can expect things are patches, [PATCH]
>>>> doesn't add useful information.)
>>>
>>> I don't mind [PATCH] in the subject of patch emails (maybe because
>>> nearly all my patches go to libstdc++@ as well, and not all mails on
>>> that list are patches), but it has negative value in the commit log.
>>
>> I actively like [PATCH] in the subject line because I see patch mail
>> interleaved with other mail in my inbox.
>>
>>> My mail to the libstdc++ list should have noted that [PATCH] tags in
>>> the email subject should be omitted from the summary in the first line
>>> of the commit log.
>>
>> And git format-patch/git am automatically add and remove [PATCH] appropriately.
> 
> Wrt [PATCH]: if we keep it, do we want to have a system to distinguish
> C/C++/... patches?  Do we want [C++ PATCH] or [PATCH][C++] or [C++][PATCH],
> something else?  (I find the latter two a bit ugly.)
> 

"git am --keep-non-patch" will strip sequences containing [.*PATCH.*]
(not a strict regexp, .* is anything other than ']'), and keep other
[.*] annotations.  I don't know if this applies only up to the first
non-matching sequence, or at any point.  See git-mailinfo's -b flag.
But my proposal (see post earlier) is that we should use <component>: in
the same way that libc (and, I understand, linux kernel folk) do.

R.

> Marek
> 

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 05/11/2019 02:51, Kewen.Lin wrote:
> Hi,
> 
> on 2019/11/4 下午6:29, Richard Earnshaw (lists) wrote:
>> With the move to git fairly imminent now it would be nice if we could agree on a more git-friendly style of commit messages; and, ideally, start using them now so that the converted repository can benefit from this.
>>
>> Some tools, particularly gitk or git log --oneline, can use one-line summaries from a commit's log message when listing commits.  It would be nice if we could start adopting a style that is compatible with this, so that in future commits are summarized in a useful way.  Unfortunately, some of our existing commits show no useful information with tools like this.
>>
>> Eg.
>>
>> git log --oneline
>> 2b70dbd64b5 (HEAD -> master, origin/trunk, origin/master, origin/HEAD) 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
>> 29f4f5f13b9 [C++ PATCH] cleanup check_field_decls
>> 0f931fb75ae 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
>> e9c4da22199 OpenMP] use_device_addr/use_device_ptr with Fortran allocatable/pointer arrays
>> 377311a90fa 2019-11-01  Kewen Lin  <linkw@gcc.gnu.org>
> 
> Sorry for the awful commit messages and thanks a lot for raising this up to stop me from stumbling continuously.
> 
> I just updated all my svn commit comments by "svn propedit svn:log --revprop -r N --editor-cmd vim",
> but I guess it won't help any more if the upcoming git repo will come from some existing mirror?
> 
> 
> BR,
> Kewen
> 

Sorry, I wasn't intending to victimise you.  It just so happened that
you had several commits at the head of my tree when I used the command.

I'm not sure it's worth rewriting history.  We've so many historically
non-compliant commits that they'll never be fixed up.  But we can amend
our ways for the future.

R.

Re: Commit messages and the move to git

[Segher Boessenkool]

Hi!

On Tue, Nov 05, 2019 at 09:50:37AM -0500, David Malcolm wrote:
> FWIW my convention has been to put "[PATCH]" in the email subject line
> for patches I want reviewed, and "[committed]" for patches that I've
> already self-approved (or are obvious) and thus don't need review.

And there is [RFC] as well.

As already noted, the advantage of [PATCH] is that many tools know how
to handle that, already, so it may fit into your workflow better (git am
removes *all* leading bracketed strings, by default).

Also making a mail that can just be applied with git-am is useful if you
want other people to be able to commit your patches.  We usually commit
our own patches, but this is still important for people who want to test
out a patch, etc.

I recommend preparing your patches with git format-patch: it takes care
of all details for you.  You still should follow some rules, like using
scissors lines, and maximum line length 72, etc., but it makes mails
that follow all our rules for mime encoding and the like.

> I'm not too bothered about the precise format FWIW - maybe it's better
> not to be too prescriptive about the format, beyond "make them concise,
> and useful for you and your fellow maintainers"?

+2

If we want to standardise on other things, like have subjects like for
example "combine: Frob the fubar" (and what those tags should be exactly)
that will work itself out hopefully.  As long as subjects are nice and
useful, everyone should be happy.

> I try to use the
> same message as the email subject line, to make cross-referencing
> between the mailing list and source repos easier when doing
> "archaeology".

I use the whole email as commit message.  This works quite well imo, and
it's the "standard" way of using git.  This also works nicely with
patchwork, if anyone but me uses that still :-)

> I also tend to put in the "blurb" from the email into the commit
> message, especially if it's a pertinent high-level description of the
> purpose of the *change* (as opposed to a description of the *code*,
> which should live in a comment in the code, rather than the metadata).

Purpose and mechanics and whatnot, yeah -- but of the change, indeed: it
should be text relevant to people who want to know what changed (and why).
Anything you would put in the mail thread that people looking at the
committed patches would still like to see.

> > I tend to put the PR number at the beginning of the line, but I don't
> > object to putting it at the end instead.

I don't think we need to standardise this, certainly not before we have
enough experience with this.  Everyone works differently, we should just
figure out a way we can work together best.  A PR # at the start of the
subject can be useful, if it leaves enough space for other important info.


Segher

Re: Commit messages and the move to git

[Eric S. Raymond]

Jeff Law <law@redhat.com>:
> On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote:
> > With the move to git fairly imminent now it would be nice if we could
> > agree on a more git-friendly style of commit messages; and, ideally,
> > start using them now so that the converted repository can benefit from
> > this.
> > 
> > Some tools, particularly gitk or git log --oneline, can use one-line
> > summaries from a commit's log message when listing commits.  It would be
> > nice if we could start adopting a style that is compatible with this, so
> > that in future commits are summarized in a useful way.  Unfortunately,
> > some of our existing commits show no useful information with tools like
> > this.
> I'd suggest we sync policy with glibc.  They're further along on the
> ChangeLog issues.  Whatever they do in this space we should follow --
> aren't we going to be using some of their hooks/scripts?

Note that my reposurgeon conversion recipe runs gitify on the repository.

From the documentation:

    Attempt to massage comments into a git-friendly form with a blank
    separator line after a summary line.  This code assumes it can insert
    a blank line if the first line of the comment ends with '.', ',', ':',
    ';', '?', or '!'.  If the separator line is already present, the comment
    won't be touched.

    Takes a selection set, defaulting to all commits and tags.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 07/11/2019 14:27, Eric S. Raymond wrote:
> Jeff Law <law@redhat.com>:
>> On 11/4/19 3:29 AM, Richard Earnshaw (lists) wrote:
>>> With the move to git fairly imminent now it would be nice if we could
>>> agree on a more git-friendly style of commit messages; and, ideally,
>>> start using them now so that the converted repository can benefit from
>>> this.
>>>
>>> Some tools, particularly gitk or git log --oneline, can use one-line
>>> summaries from a commit's log message when listing commits.  It would be
>>> nice if we could start adopting a style that is compatible with this, so
>>> that in future commits are summarized in a useful way.  Unfortunately,
>>> some of our existing commits show no useful information with tools like
>>> this.
>> I'd suggest we sync policy with glibc.  They're further along on the
>> ChangeLog issues.  Whatever they do in this space we should follow --
>> aren't we going to be using some of their hooks/scripts?
> 
> Note that my reposurgeon conversion recipe runs gitify on the repository.
> 
>  From the documentation:
> 
>      Attempt to massage comments into a git-friendly form with a blank
>      separator line after a summary line.  This code assumes it can insert
>      a blank line if the first line of the comment ends with '.', ',', ':',
>      ';', '?', or '!'.  If the separator line is already present, the comment
>      won't be touched.
> 
>      Takes a selection set, defaulting to all commits and tags.
> 

Which makes me wonder if, given a commit log of the form:


2019-10-30  Richard Biener  <rguenther@suse.de>

         PR tree-optimization/92275
         * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
         Copy all loop-closed PHIs.

         * gcc.dg/torture/pr92275.c: New testcase.

Where the first line is a ChangeLog style date and author, we could spot 
the PR line below that and hoist it up as a more useful summary (perhaps 
by copying it rather than moving it).

It wouldn't fix all commits, but even just doing this for those that 
have PRs would be a help.

R.

Re: Commit messages and the move to git

[Eric S. Raymond]

Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
> Which makes me wonder if, given a commit log of the form:
> 
> 
> 2019-10-30  Richard Biener  <rguenther@suse.de>
> 
>         PR tree-optimization/92275
>         * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
>         Copy all loop-closed PHIs.
> 
>         * gcc.dg/torture/pr92275.c: New testcase.
> 
> Where the first line is a ChangeLog style date and author, we could spot the
> PR line below that and hoist it up as a more useful summary (perhaps by
> copying it rather than moving it).
> 
> It wouldn't fix all commits, but even just doing this for those that have
> PRs would be a help.

Speaking from lots of experience with converting old repositories that
exhibited similar comment conventions, I would be nervous about trying
to do this entirely mechanically.  I think the risk of mangling text
that is not fornatted as you expect - and not noticing that until the 
friction cost of fixing it has escalated - is rather high.

On the other hand, reposurgeon allows a semi-neechanized attack on
the problem that I think would work well, because I've done similar 
things in ither coversions.

There's a pair of commands that allow you to (a) extract comments from
a range of commits into a message list that looks like an RFC822
mailbox file, (b) modify those comments, and (c) weave the the message
list reliably back into the repository.

If it were me doing this job, I'd write a reposurgeon command that
extracts all the comments containing PR strings into a message box
Then I'd write an Emacs macro that moves to the next nessage and
hoists its PR line.

Then I'd walk through the comments applying the macro and keeping an eye on 
them for cases where what the macro doesn't do quite the right thing and 
using undo and hand-editing to recover.  Human eyes are very good at 
spotting anomalies in an expected flow of textm and once you've gotten
into the rhythm of a task like this is is easily possible to filter
approximately a message per second. In round numbers, providing
the anomaly rate isn't high, that's upwards of 3000 messages per hour.

The point is that for this kind of task a hnman being who undertands 
what he's reading is likely to have a lower rate of mangling errors than
a program that doesn't.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

[-- Attachment #1: Type: text/plain, Size: 4668 bytes --]

On 09/11/2019 06:01, Eric S. Raymond wrote:
> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>> Which makes me wonder if, given a commit log of the form:
>>
>>
>> 2019-10-30  Richard Biener  <rguenther@suse.de>
>>
>>          PR tree-optimization/92275
>>          * tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
>>          Copy all loop-closed PHIs.
>>
>>          * gcc.dg/torture/pr92275.c: New testcase.
>>
>> Where the first line is a ChangeLog style date and author, we could spot the
>> PR line below that and hoist it up as a more useful summary (perhaps by
>> copying it rather than moving it).
>>
>> It wouldn't fix all commits, but even just doing this for those that have
>> PRs would be a help.
> 
> Speaking from lots of experience with converting old repositories that
> exhibited similar comment conventions, I would be nervous about trying
> to do this entirely mechanically.  I think the risk of mangling text
> that is not fornatted as you expect - and not noticing that until the
> friction cost of fixing it has escalated - is rather high.
> 
> On the other hand, reposurgeon allows a semi-neechanized attack on
> the problem that I think would work well, because I've done similar
> things in ither coversions.
> 
> There's a pair of commands that allow you to (a) extract comments from
> a range of commits into a message list that looks like an RFC822
> mailbox file, (b) modify those comments, and (c) weave the the message
> list reliably back into the repository.
> 
> If it were me doing this job, I'd write a reposurgeon command that
> extracts all the comments containing PR strings into a message box
> Then I'd write an Emacs macro that moves to the next nessage and
> hoists its PR line.
> 
> Then I'd walk through the comments applying the macro and keeping an eye on
> them for cases where what the macro doesn't do quite the right thing and
> using undo and hand-editing to recover.  Human eyes are very good at
> spotting anomalies in an expected flow of textm and once you've gotten
> into the rhythm of a task like this is is easily possible to filter
> approximately a message per second. In round numbers, providing
> the anomaly rate isn't high, that's upwards of 3000 messages per hour.
> 
> The point is that for this kind of task a hnman being who undertands
> what he's reading is likely to have a lower rate of mangling errors than
> a program that doesn't.
> 

The hook into reposurgeon is even better... it allows a more intelligent 
hook to be produced, for example the attached.

In a reposurgeon lift script you can write something like

~gcc2 msgout >gcc.commitlog
shell ./fixbugmessages
msgin <gcc.fixedprs

I wrote this script for two reasons
    1) To learn some python (finally I had a good reason to go and do 
this :)
    2) To try to improve some of our legacy commit messages, especially 
where they appear in git as just the name of the author (information 
that is already readily available in other components.

It works by scanning for commits that match a traditional ChangeLog 
style author line and then, if the commit mentions a PR, looking that
up in the Bugzilla database to extract the original component and the 
summary line from the PR.  It then produces a single line summary based 
on the PR and the summary associated with it.  So for example, a commit 
such as this one:

2019-10-30  Richard Biener  <rguenther@suse.de>

	PR tree-optimization/92275
	* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
	Copy all loop-closed PHIs.

	* gcc.dg/torture/pr92275.c: New testcase.


Would be matched and the line

    PR tree-optimization/92275 ICE: error: definition in block 11 does 
not dominate use in block 15 since r277566

added as a summary

Since there are a number of errors that over the years have crept into 
the commit logs, there are also features to try to match (where they are 
specified) the bug component against that listed in the commit log. 
That matching is fuzzy, since it too can be inaccurate: many bugs, for 
example, are classified as target in the PR, but subsequently get a 
commit component that reflects where the fix was applied.  So there are 
some filters to simplify reporting to just those categories that look 
obviously suspicious (like a fortran bug with a C component reported). 
There are also facilities to mark some commits that have been manually 
verified as clean so that they are no-longer reported.

The script generates new summary lines for nearly 43000 commits that 
would mostly have just shown the author line.  Of those about 560 are 
flagged as potentially suspicious and will need some manual checking.

R.

[-- Attachment #2: bugdb.py --]
[-- Type: text/x-python, Size: 18253 bytes --]

#!/usr/bin/python2

import requests
import json
import os.path
import codecs
import email.message, email.parser
import re
import signal

# Files that we read or write.
buglist = "bugids.list"
bugdbfile = "bugs.json"
commits_in = "gcc.commitlog"
commits_out = "gcc.fixedprs"

bugdb = {}

# Dictionary indexed by bugzilla component.  If the claimed PR component
# matches against the real component, then assume this probably an OK
# matching.  We avoid a lot of false positive warnings this way.
# A special match of "*" means we don't care in this case.  Many bugs
# are filed under, for example, bootstrap or other when in fact the
# real component will ultimately be shown in the commit log.
compalias = {
    "rtl-optimization": ["opt", "optimization", "optimisation", "optimize",
                         "middle-end", "rtl-opt", "rtl_optimization",
                         "rtl-optimizations", "rtl"],
    "tree-optimization": ["opt", "optimization", "optimisation", "optimize",
                          "middle-end", "tree-opt", "tree-optimzation",
                          "graphite", "lto", "tree-optimizations",
                          "tree-optimizer", "ipa", "tree-optimize",
                          "tree-optimizatio"],
    "java": ["gcj", "libgcj", "libjava"],
    "fastjar": ["java"],
    "libgcj": ["java", "libjava"],
    "classpath": ["libgcj", "libjava", "xml", "crypto"],
    "awt": ["classpath", "libjava"],
    "xml": ["classpath", "libjava"],
    "crypto": ["classpath", "libjava"],
    "objc++": ["obj-c++"],
    "c++": ["libstdc++", "diagnostic", "cp"],
    "c": ["diagnostic", "c-family"],
    "libstdc++": ["c++", "libstdc++-v3"],
    "libmudflap": ["mudflap"],
    "preprocessor": ["cpp", "pch"],
    "bootstrap": ["*"],
    "testsuite": ["*"],
    "regression": ["*"],
    "sanitizer": ["sanitize", "ubsan"],
    "other": ["*"],
    "middle-end": ["optimization", "rtl-optimization", "tree-optimization",
                   "tree-opt", "rtl-opt", "ipa", "lto", "middle", "middle-ed"],
    "ipa": ["middle-end", "lto"],
    "lto": ["middle-end", "ipa", "tree-optimization"],
    "target": ["*"],
    "plugins": ["*"],
    "libf2c": ["fortran", "gfortran", "libgfortran", "libfortran"],
    "fortran": ["gfortran", "libgfortran", "libfortran", "forrtran"],
    "libfortran": ["fortran", "gfortran", "libgfortran", "libfofortran"],
    "libgomp": ["fortran"],
    "gcov-profile": ["profile", "gcov"],
    "libffi": ["other"],
    "web": ["documentation"]}

# List of Legacy-IDs where the PR is correct, dispite the anomaly
# checks we perform.
whitelist = ["52862", "53125", "57958", "57959", "58705", "51884", "58535",
             "58542",
             "61329", "61770", "61960", "61984", "63783", "65127", "65128",
             "67653", "68236", "68239",
             "70062", "70542", "70625", "70932", "72072", "72259", "72260",
             "73504", "73940", "73940", "77602", "78312", "78313",
             "80793", "82490", "82518", "83609", "84217", "84295", "84531",
             "84532", "84887", "84895", "86396", "86429", "86458", "86459",
             "86460", "86461", "87066", "87189", "87511", "87512", "87632",
             "88922", "89175", "89921",
             "90004", "91308", "91504", "92158", "92585", "92658", "94054",
             "94226", "94317", "94805", "95382", "95383", "95428", "95673",
             "96396", "96626", "97373", "97375", "97537", "98412", "98926",
             "99480", "99514",
             "100206", "100207", "100209", "100371", "100851", "100961",
             "101264", "101273", "102155", "102348", "102539", "102567",
             "102799", "102920", "103268", "103279", "103308", "104948",
             "104949", "104988", "105052", "105274", "106269", "106582",
             "107816", "108045", "109166", "109167", "109168", "109169",
             "109643", "109644", "109818",
             "110131", "110132", "110627", "110975", "111818", "111947",
             "111952", "112296", "112298", "112611", "112612", "112819",
             "113095", "113119", "113121", "113137", "113627", "113628",
             "113661", "113662",
             "113701", "113702", "113703", "114482", "115200",
             "116613", "116633", "116633", "117824",
             "117852", "118025", "118034", "118142",
             "118742", "118743", "119248", "119485", "119486",
             "120497", "120498", "120499", "120523", "121334", "121338",
             "121949", "122640", "122641", "122700", "122743", "122751",
             "122798", "124362", "125025",
             "125108", "125844", "126675", "127812", "127688", "127689",
             "128272", "128573", "128649", "129871",
             "130016", "131781", "132577", "132587",
             "141646", "142724", "142725", "142833", "144976",
             "152550", "157199", "157784",
             "160456", "160476", "163777",
             "176083", "176167", "176623", "176624",
             "182943", "187842",
             "190100", "193620", "194102", "195610", "199972",
             "201377", "201378", "202642", "202937", "205753", "209250",
             "210999", "211000", "211001", "211002", "214734", "214958",
             "215345", "215386", "215804", "215806", "215807",
             "221207", "221958",
             "233033",
             "242543", "242795",
             "259105",
             "268434",
             "276571", "276987", "276993"
]

# Indexed by Legacy-ID.  Each fixup may contain either the correct PR
# for this commit or an alternative summary string.  If the latter, this
# will form the entire summary for the commit.
fixups = {
    "57986": {"PR": "7792"},
    "52818": {"PR": "6479"},
    "65177": {"PR": "8808"},
    "65181": {"PR": "8808"},
    "68117": {"PR": "10712"},
    "68118": {"PR": "10712"},
    "71157": {"PR": "11867"},
    "71159": {"PR": "11867"},
    "71856": {"PR": "11415"},
    "75457": {"PR": "12815"},
    "81771": {"PR": "15204"},
    "82028": {"summary": "Multiple fixes: PRs 14692, 15274 and 15463"},
    "84508": {"PR": "16455"},
    "84522": {"PR": "15754"},
    "85966": {"PR": "16935"},
    "86431.1": {"summary": "Revert earlier fix for PR 14029"},
    "86431.2": {"summary": "Revert earlier fix for PR 14029"},
    "93620": {"PR": "19009"},
    "94658": {"PR": "19736"},
    "94889": {"PR": "19634"},
    "96560": {"PR": "20490"},
    "107451": {"PR": "24236"},
    "110063": {"summary": "PR25024, PR20881, PR23308, PR25538 and PR25710 - Procedure references"},
    "114667": {"PR": "27648"},
    "115858": {"PR": "28452"},
    "122127": {"PR": "30795"},
    "122980": {"PR": "31025"},
    "141612": {"PR": "32519"},
    "146134": {"PR": "38668"},
    "146593": {"PR": "39632"},
    "146650": {"PR": "39632"},
    "151112": {"PR": "28039"},
    "158393": {"PR": "43741"},
    "171924": {"PR": "48401"},
    "174228": {"PR": "46005"},
    "174235": {"PR": "46005"},
    "179230": {"PR": "45012"},
    "188077": {"PR": "52700"},
    "188078": {"PR": "52700"},
    "188079": {"PR": "52700"},
    "206073": {"PR": "35545"},
    "206074": {"PR": "35545"},
    "224527": {"PR": "56766"},
    "268301": {"PR": "89020"},
    "249711": {"summary": "Revert: backport PRs 80382, 80966"},
    "276627": {"PR": "47054"}
    }

def read_bugdb(dbfile):
    try:
        with open(dbfile, "r") as f:
            bugdb.update(json.load(f))
            print(len(bugdb))
            f.close()
    except:
        return

def write_bugdb(dbfile):
    try:
        os.delete(dbfile + ".bak")
    except:
        pass
    try:
        os.rename(dbfile, dbfile + ".bak")
    except:
        pass
    try:
        with open(dbfile, "w") as f:
            json.dump(bugdb, f)
            f.close()
    except:
        print("Failed to write" + dbfile)
        exit()

def fetch_sublist(sublist):
    url = 'https://gcc.gnu.org/bugzilla/rest.cgi/bug?id='
    url += ','.join([elem for elem in sublist])
    url += '&include_fields=id,summary,component,resolution'

    resp = requests.get(url)

    if resp.status_code != 200:
        print(resp.status_code)
    return resp.json()

def process(jdata):
    buglist = jdata['bugs']
    for bug in buglist:
        bugdb[str(bug['id'])] = {"summary": bug['summary'],
                                 "component": bug['component'],
                                 "resolution": bug['resolution']}

    print(len(bugdb))

def fetchall(bugids):
    f = open(bugids, "r")
    allbugids = f.read().splitlines()
    sublist = []
    for bugid in allbugids:
        if str(bugid) not in bugdb:
            #print("missing: " + id)
            sublist.append(bugid)
            if len(sublist) == 200:
                process(fetch_sublist(sublist))
                sublist = []
    for fixup in fixups.values():
        if "PR" in fixup and fixup['PR'] not in bugdb:
            sublist.append(fixup['PR'])
            if len(sublist) == 200:
                process(fetch_sublist(sublist))
                sublist = []
    if sublist:
        process(fetch_sublist(sublist))

# This is lifted from the python version of reposurgeon, since we are
# parsing objects it created.

# Since we assume python2
rspolicy = None

class RepoSurgeonEmail(email.message.Message, object):
    "Specialized email message with a distinguishing starter."
    Divider = 78 * "-"
    __hash__ = None
    def __init__(self, **kwargs):
        if rspolicy:
            # This activates the Python 3 email header handling hack
            kwargs['policy'] = rspolicy
        email.message.Message.__init__(self, **kwargs)
        self.set_unixfrom(RepoSurgeonEmail.Divider)
    @staticmethod
    def readmsg(fp):
        msg = ''
        firstline = fp.readline()
        if not firstline:
            return None
        elif not firstline.startswith(RepoSurgeonEmail.Divider):
            msg = firstline
        while True:
            line = fp.readline()
            if not line:
                break
            # Not impossible for this to get spoofed, but *highly* unlikely
            if line == "\n." + RepoSurgeonEmail.Divider + "\n":
                line = "\n" + RepoSurgeonEmail.Divider + "\n"
            if line.startswith(RepoSurgeonEmail.Divider):
                break
            msg += line
        return msg
    def payload(self):
        "Return message body - works because not multipart."
        return self.get_payload()
    def __str__(self):
        out = super(RepoSurgeonEmail, self).as_string(unixfrom=True)
        out = out.replace("\n" + RepoSurgeonEmail.Divider + "\n",
                          "\n." + RepoSurgeonEmail.Divider + "\n")
        out = out.replace("\n>From", "\nFrom")
        return out

# Close states that suggest that the bug is unlikely to be a correct
# target of a fix.
badclose = ["INVALID"]
# Would be nice to add ["WORKSFORME", "WONTFIX"], but too many false
# positives on early PRs.

# Fuzzy match a claimed bugcat against the component in the PR.  This avoids
# a number of likely false negatives without over relaxing the desire to
# detect possibly inaccurate PR numbers.
def component_mismatch(bugcat, bugid):
    # We're not bothered about case
    bugcat = bugcat.lower()
    component = bugdb[bugid]['component']
    # It's extremely unlikely that any bug classified as spam should match
    # a PR.  It's also pretty unlikely that a bug closed as INVALID would
    # do so either.  So flag up both cases.
    if (component == "spam" or bugdb[bugid]['resolution'] in badclose):
        return True
    # These blanket components lead to far too many false positives, so
    # just ignore them.  This is essentially the reverse map of the "*"
    # match later on.
    if (bugcat in ["boostrap", "bootstrap", "target", "plugins", "testsuite",
                   "other", "ice", "gcc", "translation", "regression", "build",
                   "diagnostic", "wrong-code"] or
        # These are nonesense categories, since they refer to
        # components outside of GCC.
        bugcat in ["binutils", "gas", "ld"] or
        bugcat == component):
        return False
    if component not in compalias:
        return True
    if ("*" in compalias[component] or
        bugcat in compalias[component]):
        return False
    return True

def processmsg(msg):
    multicommit = False
    payload = msg.get_payload()
    summary = None

    # Look to see if this event has a specific fixup.  Use it if so.
    if msg['Legacy-ID'] in fixups:
        fixup = fixups[msg['Legacy-ID']]
        if "PR" in fixup:
            summary = bugdb[fixup['PR']]['summary'].encode("utf-8")
            z = re.match(r"\s*\[[^\]]*[Rr]egression\s*\]\s*:?\s*(.*)", summary)
            if z:
                summary = z.group(1)
            summary = ("PR " + bugdb[fixup['PR']]['component'].encode("utf-8")
                       + "/" + fixup['PR'] + ": " + summary)
        elif "summary" in fixup:
            summary = fixup['summary']
        else:
            print("Invalid fixup for Legacy-ID " + msg['Legacy-ID'])
            exit()

    # Look to see if this event is a backport of multiple PRs.  Just
    # set the summary to a quick list if so.
    if not summary:
        allprs = re.findall(r"\b\s*PR(\s+([^/\s]+)/|\s*#?)(\d+)\b", payload)
        allprnos = list(dict.fromkeys([int(pr[2]) for pr in allprs]))
        allprnos.sort()
        if ((len(allprnos) > 3 and
             re.search(r"\b[Bb]ack ?port(ed)?\b", payload))
            or (len(allprnos) > 1 and
                re.search(r"\b[Bb]ack ?ports", payload))):
            prs = allprnos if len(allprnos) < 10 else allprnos[:10]
            #print prs[0]
            summary = "Backport PRs " + str(prs[0])
            for pr in prs[1:]:
                summary += ", " + str(pr)
            if len(allprnos) > 10:
                summary += " and more"

    if not summary:
        lines = payload.splitlines()
        while lines and lines[0] == "":
            lines = lines[1:]
        if not lines:
            return None
        x = re.match(r"\d{4}-\d{2}-\d{2}\s+.+\s<[\w.]+@[\w.-]+>",lines[0])
        if x:
            if len(lines) > 2:
                for line in lines[2:]:
                    if (line != lines[0] and
                        re.match(r"\d{4}-\d{2}-\d{2}\s+.+\s<[\w.]+@[\w.-]+>",
                                 line)):
                        multicommit = True
                        break
        else:
            # Some messages begin with just the PR number, we can
            # handle these the same way.  In this case, only match if
            # the line only contains the PR number.
            x = re.match(r"\s*PR(\s+[^/\s]+/|\s*#?)(\d+)\s*$", lines[0])
            if not x:
                return None
        if multicommit:
            summary = "[multiple commits]"
            bugid = ""
        else:
            y = re.search(r"(^|\s+|[/\(\[])PR(\s+([^/\s]+)/|\s*#?)(\d+)\b",
                          payload)
            if not y:
                return None
            bugcat = y.group(3)
            bugid = y.group(4)
            if bugid not in bugdb:
                #print("PR " + bugid + " not found in database")
                return None
            summary = bugdb[bugid]['summary'].encode("utf-8")
            # Early on there were multiple GNATS databases for bugs;
            # later they were merged into a single database, but the
            # PR numbers were changed.  Don't trust bugs below 1000
            # unless the component matches the one mentioned in the
            # log (if it even has one).
            if (int(bugid) < 1000 and
                (bugcat == None or bugcat != bugdb[bugid]['component'])):
                print("E" + msg['Event-Number'] + "(r" + msg['Legacy-ID']
                      + "): Ignoring PR " + bugid
                      + " - no component or component mismatch")
                return None
            elif (bugcat != None and msg['Legacy-ID'] not in whitelist
                  and component_mismatch(bugcat, bugid)):
                problem = ("E" + msg['Event-Number'] + "(r" + msg['Legacy-ID']
                           + "): '" + bugcat + "/" + bugid + "'")
                if (bugdb[bugid]['resolution'] in badclose):
                    problem += " closed as " + bugdb[bugid]['resolution'].encode("utf-8")
                    summary += (" [checkme: "
                                + bugdb[bugid]['resolution'].encode("utf-8")
                                + " SVN r" + msg['Legacy-ID'] + "]")
                else:
                    problem += " mismatch PR " + bugdb[bugid]['component'].encode("utf-8")
                    summary += (" [checkme: " + bugcat + " SVN r"
                                + msg['Legacy-ID'] + "]")
                print(problem)

            z = re.match(r"\s*\[[^\]]*[Rr]egression\s*\]\s*:?\s*(.*)", summary)
            if z:
                #print(summary)
                summary = z.group(1)
            summary = ("PR " + bugdb[bugid]['component'].encode("utf-8")
                       + "/" + bugid + ": " + summary)

    newmsg = RepoSurgeonEmail()

    # All messages should have an event number, so this will hopefully
    # raise an exception if it fails
    newmsg['Event-Number'] = msg['Event-Number']
    if "Check-Text" in msg:
        newmsg['Check-Text'] = msg['Check-Text']
    # We must copy the tag name if it exists.
    if "Tag-Name" in msg:
        newmsg['Tag-Name'] = msg['Tag-Name']
    try:
        newmsg.set_payload(summary + "\n\n" + payload)
        return str(newmsg)
    except:
        print("Unicode??? Cannot format message for Event "
              + msg['Event-Number'] +
              (summary if bugid == "" else (" PR " + bugid)))
        return None

def main():
    read_bugdb(bugdbfile)
    try:
        fetchall(buglist)
    except KeyboardInterrupt:
        write_bugdb(bugdbfile)
        exit()

    write_bugdb(bugdbfile)

    commitlog = open(commits_in, "r")
    newlog = open(commits_out, "w")

    while True:
        msg = RepoSurgeonEmail.readmsg(commitlog)
        if not msg:
            break
        newmsg = processmsg(email.message_from_string(msg))
        if newmsg:
            newlog.write(newmsg)

    newlog.close()
    commitlog.close()

if __name__ == '__main__':
    main()

[-- Attachment #3: fixbugmessages --]
[-- Type: text/plain, Size: 416 bytes --]

#!/bin/sh

# Note the largest bugid is currently less than 100000, so we strip
# off any above that as they must clearly be bogus

egrep "\bPR( ?#?[0-9]+|[ 	]+[^/ 	]+/[0-9]+)([[:punct:]]|[ 	]|$)"\
      gcc.commitlog | \
    sed -E "s:\bPR( [a-zA-Z][-+a-zA-Z0-9]*/| ?#?)([0-9][0-9]*).*:x\2:" | \
    sed -E "s/.*x([0-9][0-9]*)/\1/" | \
    sort -n | \
    uniq | \
    sed -e "/.......*/d" > bugids.list

./bugdb.py

Re: Commit messages and the move to git

[Segher Boessenkool]

Hi!

On Mon, Nov 18, 2019 at 03:32:06PM +0000, Richard Earnshaw (lists) wrote:
> I wrote this script for two reasons
>    1) To learn some python (finally I had a good reason to go and do 
> this :)

So I am last now?  Heh.

>    2) To try to improve some of our legacy commit messages, especially 
> where they appear in git as just the name of the author (information 
> that is already readily available in other components.

> So for example, a commit such as this one:
> 
> 2019-10-30  Richard Biener  <rguenther@suse.de>
> 
> 	PR tree-optimization/92275
> 	* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
> 	Copy all loop-closed PHIs.
> 
> 	* gcc.dg/torture/pr92275.c: New testcase.
> 
> 
> Would be matched and the line
> 
>    PR tree-optimization/92275 ICE: error: definition in block 11 does 
> not dominate use in block 15 since r277566
> 
> added as a summary

That immediately shows some of the shortcomings of this approach: the
subject line is much too long, but more importantly, it doesn't make
much sense: it is not what the patch does, it is the description of a
bug that is related in some way to this patch.  It is not uncommon for
a commit to not fix the problem mentioned in the bug report (if it *is*
a problem!), or not fix it completely.

Then again, changing all such subject lines to read "patch" could also
already be considered an improvement.


Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 15:55, Segher Boessenkool wrote:
> Hi!
> 
> On Mon, Nov 18, 2019 at 03:32:06PM +0000, Richard Earnshaw (lists) wrote:
>> I wrote this script for two reasons
>>     1) To learn some python (finally I had a good reason to go and do
>> this :)
> 
> So I am last now?  Heh.
> 
>>     2) To try to improve some of our legacy commit messages, especially
>> where they appear in git as just the name of the author (information
>> that is already readily available in other components.
> 
>> So for example, a commit such as this one:
>>
>> 2019-10-30  Richard Biener  <rguenther@suse.de>
>>
>> 	PR tree-optimization/92275
>> 	* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_loops):
>> 	Copy all loop-closed PHIs.
>>
>> 	* gcc.dg/torture/pr92275.c: New testcase.
>>
>>
>> Would be matched and the line
>>
>>     PR tree-optimization/92275 ICE: error: definition in block 11 does
>> not dominate use in block 15 since r277566
>>
>> added as a summary
> 
> That immediately shows some of the shortcomings of this approach: the
> subject line is much too long, but more importantly, it doesn't make
> much sense: it is not what the patch does, it is the description of a
> bug that is related in some way to this patch.  It is not uncommon for
> a commit to not fix the problem mentioned in the bug report (if it *is*
> a problem!), or not fix it completely.
> 
> Then again, changing all such subject lines to read "patch" could also
> already be considered an improvement.
> 

Well the real question is whether such a summary is worse than the 
current situation of just printing the author in the wrong field.  I 
personally don't think it is.   As for the over-long lines, truncating 
them is trivial, if that would be better.  It's also easy to drop the 
component field.  I put it in for now as it helps with verifying those 
commits that look a bit suspicious (I put even more info in for now in 
that case, but would not expect that in a final conversion).

There are about 560 commits where the code highlights that the data 
might be suspect (usually a category mismatch).  I'd like to audit those 
if we are to go ahead with this; but I don't want to waste time on that 
if nobody wants this information as a careful audit will take quite a 
lot of effort.  I've already spotted over 40 commits where the PR was 
incorrect and included fixed PRs for those commits.

R.

Re: Commit messages and the move to git

[Segher Boessenkool]

Hi Richard,

On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) wrote:
> On 18/11/2019 15:55, Segher Boessenkool wrote:
> >That immediately shows some of the shortcomings of this approach: the
> >subject line is much too long, but more importantly, it doesn't make
> >much sense: it is not what the patch does, it is the description of a
> >bug that is related in some way to this patch.  It is not uncommon for
> >a commit to not fix the problem mentioned in the bug report (if it *is*
> >a problem!), or not fix it completely.
> >
> >Then again, changing all such subject lines to read "patch" could also
> >already be considered an improvement.
> 
> Well the real question is whether such a summary is worse than the 
> current situation of just printing the author in the wrong field.  I 
> personally don't think it is.

I think that non-obviously-wrong-but-still-wrong info is not something
we should introduce.  And, I think this will happen a *lot*.

Maybe you can just put in artificial subjects like "Patch related to
PR12345" or the like?  That is correct, displays a lot better, and is
at least as useful (imo).

> There are about 560 commits where the code highlights that the data 
> might be suspect (usually a category mismatch).

What about commits that mention multiple PRs?  What do you do for those?
(Are there as many of those as I think, anyway?)  With normally very short
subjects you could put all of them in there :-)


Segher

Re: Commit messages and the move to git

[Nicholas Krause]

On 11/18/19 12:20 PM, Nicholas Krause wrote:
>
> On 11/18/19 12:11 PM, Segher Boessenkool wrote:
>> Hi Richard,
>>
>> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) 
>> wrote:
>>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>>> That immediately shows some of the shortcomings of this approach: the
>>>> subject line is much too long, but more importantly, it doesn't make
>>>> much sense: it is not what the patch does, it is the description of a
>>>> bug that is related in some way to this patch.  It is not uncommon for
>>>> a commit to not fix the problem mentioned in the bug report (if it 
>>>> *is*
>>>> a problem!), or not fix it completely.
>>>>
>>>> Then again, changing all such subject lines to read "patch" could also
>>>> already be considered an improvement.
>>> Well the real question is whether such a summary is worse than the
>>> current situation of just printing the author in the wrong field.  I
>>> personally don't think it is.
>> I think that non-obviously-wrong-but-still-wrong info is not something
>> we should introduce.  And, I think this will happen a *lot*.
>>
>> Maybe you can just put in artificial subjects like "Patch related to
>> PR12345" or the like?  That is correct, displays a lot better, and is
>> at least as useful (imo).
>
> I don't see but other projects  mention PRS or Bugzilla ids but
>
> more common in my experience is just mentioned the commit
>
> ids. For example this fixes commit id x introducing PR x. Commit
>
> ids are know good so having them linked in commit messages
>
> is much easier to track then PRs, I can just use git log -p commit id.
>
>>
>>> There are about 560 commits where the code highlights that the data
>>> might be suspect (usually a category mismatch).
>> What about commits that mention multiple PRs?  What do you do for those?
>> (Are there as many of those as I think, anyway?)  With normally very 
>> short
>> subjects you could put all of them in there :-)
>
> See my above but for this you would just state the main issue(s) in 
> the commit
>
> message and in the body what commits/PRs are being handled.
>
> Not sure if that works for everyone but that's normally the best way 
> in my
>
> experience,
>
> Nick
>
> Sorry but cced the others as this was a misclick.
>>
>> Segher

Re: Commit messages and the move to git

[Nicholas Krause]

On 11/18/19 12:23 PM, Nicholas Krause wrote:
>
> On 11/18/19 12:20 PM, Nicholas Krause wrote:
>>
>> On 11/18/19 12:11 PM, Segher Boessenkool wrote:
>>> Hi Richard,
>>>
>>> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) 
>>> wrote:
>>>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>>>> That immediately shows some of the shortcomings of this approach: the
>>>>> subject line is much too long, but more importantly, it doesn't make
>>>>> much sense: it is not what the patch does, it is the description of a
>>>>> bug that is related in some way to this patch.  It is not uncommon 
>>>>> for
>>>>> a commit to not fix the problem mentioned in the bug report (if it 
>>>>> *is*
>>>>> a problem!), or not fix it completely.
>>>>>
>>>>> Then again, changing all such subject lines to read "patch" could 
>>>>> also
>>>>> already be considered an improvement.
>>>> Well the real question is whether such a summary is worse than the
>>>> current situation of just printing the author in the wrong field.  I
>>>> personally don't think it is.
>>> I think that non-obviously-wrong-but-still-wrong info is not something
>>> we should introduce.  And, I think this will happen a *lot*.
>>>
>>> Maybe you can just put in artificial subjects like "Patch related to
>>> PR12345" or the like?  That is correct, displays a lot better, and is
>>> at least as useful (imo).
>>
>> I don't see but other projects  mention PRS or Bugzilla ids but
>>
>> more common in my experience is just mentioned the commit
>>
>> ids. For example this fixes commit id x introducing PR x. Commit
>>
>> ids are know good so having them linked in commit messages
>>
>> is much easier to track then PRs, I can just use git log -p commit id.
>>
>>>
>>>> There are about 560 commits where the code highlights that the data
>>>> might be suspect (usually a category mismatch).
>>> What about commits that mention multiple PRs?  What do you do for 
>>> those?
>>> (Are there as many of those as I think, anyway?)  With normally very 
>>> short
>>> subjects you could put all of them in there :-)
>>
>> See my above but for this you would just state the main issue(s) in 
>> the commit
>>
>> message and in the body what commits/PRs are being handled.
>>
>> Not sure if that works for everyone but that's normally the best way 
>> in my
>>
>> experience,
>>
>> Nick
>>
>> Sorry but cced the others as this was a misclick.

One of the emails CCed was boucing so I just fixed that as well.

Nick

>>
>>>
>>> Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]

On 18/11/2019 17:11, Segher Boessenkool wrote:
> Hi Richard,
> 
> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>> That immediately shows some of the shortcomings of this approach: the
>>> subject line is much too long, but more importantly, it doesn't make
>>> much sense: it is not what the patch does, it is the description of a
>>> bug that is related in some way to this patch.  It is not uncommon for
>>> a commit to not fix the problem mentioned in the bug report (if it *is*
>>> a problem!), or not fix it completely.
>>>
>>> Then again, changing all such subject lines to read "patch" could also
>>> already be considered an improvement.
>>
>> Well the real question is whether such a summary is worse than the
>> current situation of just printing the author in the wrong field.  I
>> personally don't think it is.
> 
> I think that non-obviously-wrong-but-still-wrong info is not something
> we should introduce.  And, I think this will happen a *lot*.
> 
> Maybe you can just put in artificial subjects like "Patch related to
> PR12345" or the like?  That is correct, displays a lot better, and is
> at least as useful (imo).
> 
>> There are about 560 commits where the code highlights that the data
>> might be suspect (usually a category mismatch).
> 
> What about commits that mention multiple PRs?  What do you do for those?
> (Are there as many of those as I think, anyway?)  With normally very short
> subjects you could put all of them in there :-)
> 

Depends on the context.  If there look to be multiple date-stamp-author 
patterns and the lines are not identical we put:

[multiple commits]

If there are more that three PRs and the word backport appears in the 
text, then it generates a 'backport' summary of the form

Backport PRs 91606, 91772, 91790, 91812, 91968

or if there are more than about 10 prs,

Backport PRs 41611, 41905, 41906, 41961, 42006, 42025, 42057, 42069, 
42078, 42084 and more

it's easy to change the thresholds.

Otherwise we just pick the first PR found.  The assumption in this case 
is that PRs are related and thus one summary is likely as good as another.

Yes, we can just print PR numbers, and we could print multiple numbers; 
but generally I find that less helpful than the summary.

Finally, note that this does *not* delete any information.  The summary 
is added in addition to the existing text rather than replacing it.

I've attached a sample from the start of the fixed list - the full list 
is far too big to post to give a flavour of how the script currently 
works.  Note that annotations of the form [checkme: ....] in the summary 
are for diagnostic purposes.  These are where heuristics suggest that 
there's a higher than normal chance that the PR number is incorrect and 
that manual auditing is recommended.  Such annotations would not be 
appropriate in the final conversion.


[-- Attachment #2: fixed.xz --]
[-- Type: application/x-xz, Size: 30136 bytes --]

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 17:25, Nicholas Krause wrote:
> 
> On 11/18/19 12:23 PM, Nicholas Krause wrote:
>>
>> On 11/18/19 12:20 PM, Nicholas Krause wrote:
>>>
>>> On 11/18/19 12:11 PM, Segher Boessenkool wrote:
>>>> Hi Richard,
>>>>
>>>> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) 
>>>> wrote:
>>>>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>>>>> That immediately shows some of the shortcomings of this approach: the
>>>>>> subject line is much too long, but more importantly, it doesn't make
>>>>>> much sense: it is not what the patch does, it is the description of a
>>>>>> bug that is related in some way to this patch.  It is not uncommon 
>>>>>> for
>>>>>> a commit to not fix the problem mentioned in the bug report (if it 
>>>>>> *is*
>>>>>> a problem!), or not fix it completely.
>>>>>>
>>>>>> Then again, changing all such subject lines to read "patch" could 
>>>>>> also
>>>>>> already be considered an improvement.
>>>>> Well the real question is whether such a summary is worse than the
>>>>> current situation of just printing the author in the wrong field.  I
>>>>> personally don't think it is.
>>>> I think that non-obviously-wrong-but-still-wrong info is not something
>>>> we should introduce.  And, I think this will happen a *lot*.
>>>>
>>>> Maybe you can just put in artificial subjects like "Patch related to
>>>> PR12345" or the like?  That is correct, displays a lot better, and is
>>>> at least as useful (imo).
>>>
>>> I don't see but other projects  mention PRS or Bugzilla ids but
>>>
>>> more common in my experience is just mentioned the commit
>>>
>>> ids. For example this fixes commit id x introducing PR x. Commit
>>>
>>> ids are know good so having them linked in commit messages
>>>
>>> is much easier to track then PRs, I can just use git log -p commit id.
>>>
>>>>
>>>>> There are about 560 commits where the code highlights that the data
>>>>> might be suspect (usually a category mismatch).
>>>> What about commits that mention multiple PRs?  What do you do for 
>>>> those?
>>>> (Are there as many of those as I think, anyway?)  With normally very 
>>>> short
>>>> subjects you could put all of them in there :-)
>>>
>>> See my above but for this you would just state the main issue(s) in 
>>> the commit
>>>
>>> message and in the body what commits/PRs are being handled.
>>>
>>> Not sure if that works for everyone but that's normally the best way 
>>> in my
>>>
>>> experience,
>>>
>>> Nick
>>>
>>> Sorry but cced the others as this was a misclick.
> 
> One of the emails CCed was boucing so I just fixed that as well.
> 

[strange, I'm not seeing bounces].

> Nick
> 
>>>
>>>>
>>>> Segher

SVN commit Ids can't be fixed here.  Not least because we don't know the 
SHA code for the git commit at this point.  For legacy commit id's we'll 
just need to keep the existing SVN repo available, so that folks can 
look at it with, say, viewcvs.

R.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 17:46, Richard Earnshaw (lists) wrote:
> On 18/11/2019 17:25, Nicholas Krause wrote:
>>
>> On 11/18/19 12:23 PM, Nicholas Krause wrote:
>>>
>>> On 11/18/19 12:20 PM, Nicholas Krause wrote:
>>>>
>>>> On 11/18/19 12:11 PM, Segher Boessenkool wrote:
>>>>> Hi Richard,
>>>>>
>>>>> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) 
>>>>> wrote:
>>>>>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>>>>>> That immediately shows some of the shortcomings of this approach: 
>>>>>>> the
>>>>>>> subject line is much too long, but more importantly, it doesn't make
>>>>>>> much sense: it is not what the patch does, it is the description 
>>>>>>> of a
>>>>>>> bug that is related in some way to this patch.  It is not 
>>>>>>> uncommon for
>>>>>>> a commit to not fix the problem mentioned in the bug report (if 
>>>>>>> it *is*
>>>>>>> a problem!), or not fix it completely.
>>>>>>>
>>>>>>> Then again, changing all such subject lines to read "patch" could 
>>>>>>> also
>>>>>>> already be considered an improvement.
>>>>>> Well the real question is whether such a summary is worse than the
>>>>>> current situation of just printing the author in the wrong field.  I
>>>>>> personally don't think it is.
>>>>> I think that non-obviously-wrong-but-still-wrong info is not something
>>>>> we should introduce.  And, I think this will happen a *lot*.
>>>>>
>>>>> Maybe you can just put in artificial subjects like "Patch related to
>>>>> PR12345" or the like?  That is correct, displays a lot better, and is
>>>>> at least as useful (imo).
>>>>
>>>> I don't see but other projects  mention PRS or Bugzilla ids but
>>>>
>>>> more common in my experience is just mentioned the commit
>>>>
>>>> ids. For example this fixes commit id x introducing PR x. Commit
>>>>
>>>> ids are know good so having them linked in commit messages
>>>>
>>>> is much easier to track then PRs, I can just use git log -p commit id.
>>>>
>>>>>
>>>>>> There are about 560 commits where the code highlights that the data
>>>>>> might be suspect (usually a category mismatch).
>>>>> What about commits that mention multiple PRs?  What do you do for 
>>>>> those?
>>>>> (Are there as many of those as I think, anyway?)  With normally 
>>>>> very short
>>>>> subjects you could put all of them in there :-)
>>>>
>>>> See my above but for this you would just state the main issue(s) in 
>>>> the commit
>>>>
>>>> message and in the body what commits/PRs are being handled.
>>>>
>>>> Not sure if that works for everyone but that's normally the best way 
>>>> in my
>>>>
>>>> experience,
>>>>
>>>> Nick
>>>>
>>>> Sorry but cced the others as this was a misclick.
>>
>> One of the emails CCed was boucing so I just fixed that as well.
>>
> 
> [strange, I'm not seeing bounces].

Ah! someone dropped an S out of Eric's domain.

> 
>> Nick
>>
>>>>
>>>>>
>>>>> Segher
> 
> SVN commit Ids can't be fixed here.  Not least because we don't know the 
> SHA code for the git commit at this point.  For legacy commit id's we'll 
> just need to keep the existing SVN repo available, so that folks can 
> look at it with, say, viewcvs.
> 
> R.

Re: Commit messages and the move to git

[Nicholas Krause]

On 11/18/19 12:46 PM, Richard Earnshaw (lists) wrote:
> On 18/11/2019 17:25, Nicholas Krause wrote:
>>
>> On 11/18/19 12:23 PM, Nicholas Krause wrote:
>>>
>>> On 11/18/19 12:20 PM, Nicholas Krause wrote:
>>>>
>>>> On 11/18/19 12:11 PM, Segher Boessenkool wrote:
>>>>> Hi Richard,
>>>>>
>>>>> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) 
>>>>> wrote:
>>>>>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>>>>>> That immediately shows some of the shortcomings of this 
>>>>>>> approach: the
>>>>>>> subject line is much too long, but more importantly, it doesn't 
>>>>>>> make
>>>>>>> much sense: it is not what the patch does, it is the description 
>>>>>>> of a
>>>>>>> bug that is related in some way to this patch.  It is not 
>>>>>>> uncommon for
>>>>>>> a commit to not fix the problem mentioned in the bug report (if 
>>>>>>> it *is*
>>>>>>> a problem!), or not fix it completely.
>>>>>>>
>>>>>>> Then again, changing all such subject lines to read "patch" 
>>>>>>> could also
>>>>>>> already be considered an improvement.
>>>>>> Well the real question is whether such a summary is worse than the
>>>>>> current situation of just printing the author in the wrong field.  I
>>>>>> personally don't think it is.
>>>>> I think that non-obviously-wrong-but-still-wrong info is not 
>>>>> something
>>>>> we should introduce.  And, I think this will happen a *lot*.
>>>>>
>>>>> Maybe you can just put in artificial subjects like "Patch related to
>>>>> PR12345" or the like?  That is correct, displays a lot better, and is
>>>>> at least as useful (imo).
>>>>
>>>> I don't see but other projects  mention PRS or Bugzilla ids but
>>>>
>>>> more common in my experience is just mentioned the commit
>>>>
>>>> ids. For example this fixes commit id x introducing PR x. Commit
>>>>
>>>> ids are know good so having them linked in commit messages
>>>>
>>>> is much easier to track then PRs, I can just use git log -p commit id.
>>>>
>>>>>
>>>>>> There are about 560 commits where the code highlights that the data
>>>>>> might be suspect (usually a category mismatch).
>>>>> What about commits that mention multiple PRs?  What do you do for 
>>>>> those?
>>>>> (Are there as many of those as I think, anyway?)  With normally 
>>>>> very short
>>>>> subjects you could put all of them in there :-)
>>>>
>>>> See my above but for this you would just state the main issue(s) in 
>>>> the commit
>>>>
>>>> message and in the body what commits/PRs are being handled.
>>>>
>>>> Not sure if that works for everyone but that's normally the best 
>>>> way in my
>>>>
>>>> experience,
>>>>
>>>> Nick
>>>>
>>>> Sorry but cced the others as this was a misclick.
>>
>> One of the emails CCed was boucing so I just fixed that as well.
>>
>
> [strange, I'm not seeing bounces].
>
>> Nick
>>
>>>>
>>>>>
>>>>> Segher
>
> SVN commit Ids can't be fixed here.  Not least because we don't know 
> the SHA code for the git commit at this point.  For legacy commit id's 
> we'll just need to keep the existing SVN repo available, so that folks 
> can look at it with, say, viewcvs.
>
> R.

Richard,

That's a problem but for legacy commits keeping the old cvs around would 
be good. Other projects had the problem of moving to git but not keeping 
that data around and causing issues.  The other thing I would point out 
in this discussion is to start figuring out history policies on branches 
e.t.c for merges,

cherry picking and bisect. Merges are the obvious one but bisect and 
cherry picking will depend on

the history choices over time as how useful they may become.

I've yet to see history choices discussed whether it be straight linear, 
branches and merge e.t.c.

but thought I will mention it again as I did at Cauldron briefly as 
this  will not be part of the merge

but important for future planning git migration or project strategies 
and should be discussed

or added to the wiki for git migration.

Cheers,

Nick

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 17:55, Nicholas Krause wrote:
> 
> On 11/18/19 12:46 PM, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 17:25, Nicholas Krause wrote:
>>>
>>> On 11/18/19 12:23 PM, Nicholas Krause wrote:
>>>>
>>>> On 11/18/19 12:20 PM, Nicholas Krause wrote:
>>>>>
>>>>> On 11/18/19 12:11 PM, Segher Boessenkool wrote:
>>>>>> Hi Richard,
>>>>>>
>>>>>> On Mon, Nov 18, 2019 at 04:48:03PM +0000, Richard Earnshaw (lists) 
>>>>>> wrote:
>>>>>>> On 18/11/2019 15:55, Segher Boessenkool wrote:
>>>>>>>> That immediately shows some of the shortcomings of this 
>>>>>>>> approach: the
>>>>>>>> subject line is much too long, but more importantly, it doesn't 
>>>>>>>> make
>>>>>>>> much sense: it is not what the patch does, it is the description 
>>>>>>>> of a
>>>>>>>> bug that is related in some way to this patch.  It is not 
>>>>>>>> uncommon for
>>>>>>>> a commit to not fix the problem mentioned in the bug report (if 
>>>>>>>> it *is*
>>>>>>>> a problem!), or not fix it completely.
>>>>>>>>
>>>>>>>> Then again, changing all such subject lines to read "patch" 
>>>>>>>> could also
>>>>>>>> already be considered an improvement.
>>>>>>> Well the real question is whether such a summary is worse than the
>>>>>>> current situation of just printing the author in the wrong field.  I
>>>>>>> personally don't think it is.
>>>>>> I think that non-obviously-wrong-but-still-wrong info is not 
>>>>>> something
>>>>>> we should introduce.  And, I think this will happen a *lot*.
>>>>>>
>>>>>> Maybe you can just put in artificial subjects like "Patch related to
>>>>>> PR12345" or the like?  That is correct, displays a lot better, and is
>>>>>> at least as useful (imo).
>>>>>
>>>>> I don't see but other projects  mention PRS or Bugzilla ids but
>>>>>
>>>>> more common in my experience is just mentioned the commit
>>>>>
>>>>> ids. For example this fixes commit id x introducing PR x. Commit
>>>>>
>>>>> ids are know good so having them linked in commit messages
>>>>>
>>>>> is much easier to track then PRs, I can just use git log -p commit id.
>>>>>
>>>>>>
>>>>>>> There are about 560 commits where the code highlights that the data
>>>>>>> might be suspect (usually a category mismatch).
>>>>>> What about commits that mention multiple PRs?  What do you do for 
>>>>>> those?
>>>>>> (Are there as many of those as I think, anyway?)  With normally 
>>>>>> very short
>>>>>> subjects you could put all of them in there :-)
>>>>>
>>>>> See my above but for this you would just state the main issue(s) in 
>>>>> the commit
>>>>>
>>>>> message and in the body what commits/PRs are being handled.
>>>>>
>>>>> Not sure if that works for everyone but that's normally the best 
>>>>> way in my
>>>>>
>>>>> experience,
>>>>>
>>>>> Nick
>>>>>
>>>>> Sorry but cced the others as this was a misclick.
>>>
>>> One of the emails CCed was boucing so I just fixed that as well.
>>>
>>
>> [strange, I'm not seeing bounces].
>>
>>> Nick
>>>
>>>>>
>>>>>>
>>>>>> Segher
>>
>> SVN commit Ids can't be fixed here.  Not least because we don't know 
>> the SHA code for the git commit at this point.  For legacy commit id's 
>> we'll just need to keep the existing SVN repo available, so that folks 
>> can look at it with, say, viewcvs.
>>
>> R.
> 
> Richard,
> 
> That's a problem but for legacy commits keeping the old cvs around would 
> be good. Other projects had the problem of moving to git but not keeping 
> that data around and causing issues.  The other thing I would point out 
> in this discussion is to start figuring out history policies on branches 
> e.t.c for merges,
> 
> cherry picking and bisect. Merges are the obvious one but bisect and 
> cherry picking will depend on
> 
> the history choices over time as how useful they may become.
> 
> I've yet to see history choices discussed whether it be straight linear, 
> branches and merge e.t.c.
> 
> but thought I will mention it again as I did at Cauldron briefly as 
> this  will not be part of the merge
> 
> but important for future planning git migration or project strategies 
> and should be discussed
> 

Well a lot of that is a property of the conversion tool.  git svn does a 
relatively poor job of anything other than straight history (I believe 
it just ignores the non-linear information.  I don't believe any tool 
can recreate information for cherry-picking unless it's recorded in the 
SVN meta-data.  Eric would be better placed to comment here.

My own observation is that when the SVN commits have merge meta-data, 
reposurgeon will pick this up and create links across to the relevant 
branches.  It does, however seem to create far more links than a 
traditional git merge would do, especially when a sequence of commits 
are referenced.  I don't know if that's essentially unfixable, or if 
it's something Eric intends to work on; but I've seen some cases where 
there are dozens of links back to a simple sequence of svn commits and 
where, I suspect, a single link back to the most recent of that sequence 
would be all that's really wanted.

> or added to the wiki for git migration.
> 
> Cheers,
> 
> Nick
> 

R.

Re: Commit messages and the move to git

[Joseph Myers]

On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:

> Well a lot of that is a property of the conversion tool.  git svn does a
> relatively poor job of anything other than straight history (I believe it just
> ignores the non-linear information.  I don't believe any tool can recreate
> information for cherry-picking unless it's recorded in the SVN meta-data.
> Eric would be better placed to comment here.

I think the main thing to make sure of in the conversion regarding that 
issue is that cherry-picks do *not* turn into merge commits (so that e.g. 
"git tag --contains" can be reasonably accurate about which releases 
contain a given commit on master; the other piece of making "git tag 
--contains" more accurate is my list of branch and tag reparentings from 
the cvs2svn era).  That is:

* If the history on a branch includes a commit that copied a particular 
file (say, a testcase) from trunk, the fact of the copy (of some file or 
subdirectory rather than actually creating / replacing the branch itself) 
should *not* by itself, in the absence of merge property changes, suffice 
to create a history relation, because in GCC that's typically a 
cherry-pick (backports of a bug fix, including creating new testcases, are 
sometimes done in a way that creates such copy relations, for example, but 
it would be wrong for it put the corresponding trunk commit in the 
ancestry of the branch commit).

* Similarly, if the SVN merge tracking information shows that a commit was 
a cherry-pick of a single revision - because SVN does track that single 
revisions were merged somewhere.  (reposurgeon definitely has logic for 
that, see the comment "Ignore single-rev fields, they are cherry-picks.".)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Segher Boessenkool]

On Mon, Nov 18, 2019 at 05:38:14PM +0000, Richard Earnshaw (lists) wrote:
> On 18/11/2019 17:11, Segher Boessenkool wrote:
> >I think that non-obviously-wrong-but-still-wrong info is not something
> >we should introduce.  And, I think this will happen a *lot*.
> >
> >Maybe you can just put in artificial subjects like "Patch related to
> >PR12345" or the like?  That is correct, displays a lot better, and is
> >at least as useful (imo).
> >
> >>There are about 560 commits where the code highlights that the data
> >>might be suspect (usually a category mismatch).
> >
> >What about commits that mention multiple PRs?  What do you do for those?
> >(Are there as many of those as I think, anyway?)  With normally very short
> >subjects you could put all of them in there :-)
> 
> Depends on the context.  If there look to be multiple date-stamp-author 
> patterns and the lines are not identical we put:
> 
> [multiple commits]
> 
> If there are more that three PRs and the word backport appears in the 
> text, then it generates a 'backport' summary of the form
> 
> Backport PRs 91606, 91772, 91790, 91812, 91968
> 
> or if there are more than about 10 prs,
> 
> Backport PRs 41611, 41905, 41906, 41961, 42006, 42025, 42057, 42069, 
> 42078, 42084 and more
> 
> it's easy to change the thresholds.
> 
> Otherwise we just pick the first PR found.  The assumption in this case 
> is that PRs are related and thus one summary is likely as good as another.
> 
> Yes, we can just print PR numbers, and we could print multiple numbers; 
> but generally I find that less helpful than the summary.
> 
> Finally, note that this does *not* delete any information.  The summary 
> is added in addition to the existing text rather than replacing it.
> 
> I've attached a sample from the start of the fixed list - the full list 
> is far too big to post to give a flavour of how the script currently 
> works.  Note that annotations of the form [checkme: ....] in the summary 
> are for diagnostic purposes.  These are where heuristics suggest that 
> there's a higher than normal chance that the PR number is incorrect and 
> that manual auditing is recommended.  Such annotations would not be 
> appropriate in the final conversion.

Random examples: (2000 lines from the end of the file):

PR target/92140: clang vs gcc optimizing with adc/sbb
PR fortran/91926: assumed rank optional
PR tree-optimization/91532: [SVE] Redundant predicated store in gcc.target/aarch64/fmla_2.c
PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1687
PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252
PR c++/92015: internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568
PR tree-optimization/92173: ICE in optab_for_tree_code, at optabs-tree.c:81
PR tree-optimization/92173: ICE in optab_for_tree_code, at optabs-tree.c:81
PR fortran/92174: runtime error: index 15 out of bounds for type 'gfc_expr *[15]

Most of these aren't helpful at all, and none of these are good commit
summaries.  The PR92173 one actually has identical commit messages btw,
huh.  Ah, the second one (r277288) has the wrong changelog, but in the
actual changelog file as well, not something any tool could fix up (or
have we reached the singularity?)


Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 18:53, Segher Boessenkool wrote:
> On Mon, Nov 18, 2019 at 05:38:14PM +0000, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 17:11, Segher Boessenkool wrote:
>>> I think that non-obviously-wrong-but-still-wrong info is not something
>>> we should introduce.  And, I think this will happen a *lot*.
>>>
>>> Maybe you can just put in artificial subjects like "Patch related to
>>> PR12345" or the like?  That is correct, displays a lot better, and is
>>> at least as useful (imo).
>>>
>>>> There are about 560 commits where the code highlights that the data
>>>> might be suspect (usually a category mismatch).
>>>
>>> What about commits that mention multiple PRs?  What do you do for those?
>>> (Are there as many of those as I think, anyway?)  With normally very short
>>> subjects you could put all of them in there :-)
>>
>> Depends on the context.  If there look to be multiple date-stamp-author 
>> patterns and the lines are not identical we put:
>>
>> [multiple commits]
>>
>> If there are more that three PRs and the word backport appears in the 
>> text, then it generates a 'backport' summary of the form
>>
>> Backport PRs 91606, 91772, 91790, 91812, 91968
>>
>> or if there are more than about 10 prs,
>>
>> Backport PRs 41611, 41905, 41906, 41961, 42006, 42025, 42057, 42069, 
>> 42078, 42084 and more
>>
>> it's easy to change the thresholds.
>>
>> Otherwise we just pick the first PR found.  The assumption in this case 
>> is that PRs are related and thus one summary is likely as good as another.
>>
>> Yes, we can just print PR numbers, and we could print multiple numbers; 
>> but generally I find that less helpful than the summary.
>>
>> Finally, note that this does *not* delete any information.  The summary 
>> is added in addition to the existing text rather than replacing it.
>>
>> I've attached a sample from the start of the fixed list - the full list 
>> is far too big to post to give a flavour of how the script currently 
>> works.  Note that annotations of the form [checkme: ....] in the summary 
>> are for diagnostic purposes.  These are where heuristics suggest that 
>> there's a higher than normal chance that the PR number is incorrect and 
>> that manual auditing is recommended.  Such annotations would not be 
>> appropriate in the final conversion.
> 
> Random examples: (2000 lines from the end of the file):
> 
> PR target/92140: clang vs gcc optimizing with adc/sbb
> PR fortran/91926: assumed rank optional
> PR tree-optimization/91532: [SVE] Redundant predicated store in gcc.target/aarch64/fmla_2.c
> PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1687
> PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252
> PR c++/92015: internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568
> PR tree-optimization/92173: ICE in optab_for_tree_code, at optabs-tree.c:81
> PR tree-optimization/92173: ICE in optab_for_tree_code, at optabs-tree.c:81
> PR fortran/92174: runtime error: index 15 out of bounds for type 'gfc_expr *[15]
> 
> Most of these aren't helpful at all, and none of these are good commit
> summaries.  The PR92173 one actually has identical commit messages btw,
> huh.  Ah, the second one (r277288) has the wrong changelog, but in the
> actual changelog file as well, not something any tool could fix up (or
> have we reached the singularity?)
> 
> 
> Segher
> 

Well we can insert a new summary for such commits, but it will appear in
addition to the existing commit entry.

The fixups table can be amended by adding a line of the form

  "<svn-rev-num>": { "summary": "<new summary>" }

to the fixups table in the script.

And that will be used in place of anything else.  This can be done for
any commit; the auto-summary only applies where the commit matches some
specific patterns.

If the table looks like it is getting too big it would be easy to push
it out to a json file that is read when the program starts.  Reading
json in python takes about two lines of code.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 18:53, Segher Boessenkool wrote:
> On Mon, Nov 18, 2019 at 05:38:14PM +0000, Richard Earnshaw (lists) wrote:
>> On 18/11/2019 17:11, Segher Boessenkool wrote:
>>> I think that non-obviously-wrong-but-still-wrong info is not something
>>> we should introduce.  And, I think this will happen a *lot*.
>>>
>>> Maybe you can just put in artificial subjects like "Patch related to
>>> PR12345" or the like?  That is correct, displays a lot better, and is
>>> at least as useful (imo).
>>>
>>>> There are about 560 commits where the code highlights that the data
>>>> might be suspect (usually a category mismatch).
>>>
>>> What about commits that mention multiple PRs?  What do you do for those?
>>> (Are there as many of those as I think, anyway?)  With normally very short
>>> subjects you could put all of them in there :-)
>>
>> Depends on the context.  If there look to be multiple date-stamp-author 
>> patterns and the lines are not identical we put:
>>
>> [multiple commits]
>>
>> If there are more that three PRs and the word backport appears in the 
>> text, then it generates a 'backport' summary of the form
>>
>> Backport PRs 91606, 91772, 91790, 91812, 91968
>>
>> or if there are more than about 10 prs,
>>
>> Backport PRs 41611, 41905, 41906, 41961, 42006, 42025, 42057, 42069, 
>> 42078, 42084 and more
>>
>> it's easy to change the thresholds.
>>
>> Otherwise we just pick the first PR found.  The assumption in this case 
>> is that PRs are related and thus one summary is likely as good as another.
>>
>> Yes, we can just print PR numbers, and we could print multiple numbers; 
>> but generally I find that less helpful than the summary.
>>
>> Finally, note that this does *not* delete any information.  The summary 
>> is added in addition to the existing text rather than replacing it.
>>
>> I've attached a sample from the start of the fixed list - the full list 
>> is far too big to post to give a flavour of how the script currently 
>> works.  Note that annotations of the form [checkme: ....] in the summary 
>> are for diagnostic purposes.  These are where heuristics suggest that 
>> there's a higher than normal chance that the PR number is incorrect and 
>> that manual auditing is recommended.  Such annotations would not be 
>> appropriate in the final conversion.
> 
> Random examples: (2000 lines from the end of the file):
> 
> PR target/92140: clang vs gcc optimizing with adc/sbb
> PR fortran/91926: assumed rank optional
> PR tree-optimization/91532: [SVE] Redundant predicated store in gcc.target/aarch64/fmla_2.c
> PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1687
> PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252
> PR c++/92015: internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568
> PR tree-optimization/92173: ICE in optab_for_tree_code, at optabs-tree.c:81
> PR tree-optimization/92173: ICE in optab_for_tree_code, at optabs-tree.c:81
> PR fortran/92174: runtime error: index 15 out of bounds for type 'gfc_expr *[15]
> 
> Most of these aren't helpful at all, and none of these are good commit
> summaries.  The PR92173 one actually has identical commit messages btw,
> huh.  Ah, the second one (r277288) has the wrong changelog, but in the
> actual changelog file as well, not something any tool could fix up (or
> have we reached the singularity?)

Identical commits are normally from where the same commit is made to
multiple branches.  It's not uncommon to see this when bugs are fixed.
Of course, in the git conversion these will likely never be connected
up, since there's no metadata for the tools to work on.

Ultimately the question here is whether something like the above is more
or less useful than what we have today, which is summary lines of the form:

<date> <user> <email>

I think the above is just useless since it duplicates information
already in the short summaries, and unless we have an extraordiarily
high error rate, a summary based on the bugzilla entry is more likely to
be useful than that, even if it is far from perfect.

None of this would be necessary, of course, if we had good short
summaries already for every commit, which is why I'd like EVERYONE to
start doing that NOW, rather than waiting for the conversion to happen.

R.

Re: Commit messages and the move to git

[Segher Boessenkool]

On Mon, Nov 18, 2019 at 07:21:22PM +0000, Richard Earnshaw (lists) wrote:
> On 18/11/2019 18:53, Segher Boessenkool wrote:
> > PR target/92140: clang vs gcc optimizing with adc/sbb
> > PR fortran/91926: assumed rank optional
> > PR tree-optimization/91532: [SVE] Redundant predicated store in gcc.target/aarch64/fmla_2.c
> > PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1687
> > PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4252
> > PR c++/92015: internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568
> > PR tree-optimization/92173: ICE in optab_for_tree_code, at optabs-tree.c:81
> > PR tree-optimization/92173: ICE in optab_for_tree_code, at optabs-tree.c:81
> > PR fortran/92174: runtime error: index 15 out of bounds for type 'gfc_expr *[15]
> > 
> > Most of these aren't helpful at all, and none of these are good commit
> > summaries.  The PR92173 one actually has identical commit messages btw,
> > huh.  Ah, the second one (r277288) has the wrong changelog, but in the
> > actual changelog file as well, not something any tool could fix up (or
> > have we reached the singularity?)
> 
> Identical commits are normally from where the same commit is made to
> multiple branches.  It's not uncommon to see this when bugs are fixed.

This is an actual mistake.  The commits are not identical at all, just
the commit messages are (and the changelog entries, too).  Not something
that happens to ften, but of course I hit it in the first random thing I
pick :-)

> Ultimately the question here is whether something like the above is more
> or less useful than what we have today, which is summary lines of the form:
> 
> <date> <user> <email>

I already said I would prefer things like
  Patch related to PR323
as the patch subject lines.  No one argues that the current state of
affairs is good.  I argue that replacing this with often wrong and
irrelevant information isn't the best we can do.

> I think the above is just useless since it duplicates information
> already in the short summaries, and unless we have an extraordiarily
> high error rate, a summary based on the bugzilla entry is more likely to
> be useful than that, even if it is far from perfect.

I don't agree with this part, that is all.

> None of this would be necessary, of course, if we had good short
> summaries already for every commit, which is why I'd like EVERYONE to
> start doing that NOW, rather than waiting for the conversion to happen.

And not just a subject line, also a little bit of substance in the
commit message body text please, before the changelog.


Segher

Re: Commit messages and the move to git

[Jason Merrill]

On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
segher@kernel.crashing.org> wrote:

> On Mon, Nov 18, 2019 at 07:21:22PM +0000, Richard Earnshaw (lists) wrote:
> > On 18/11/2019 18:53, Segher Boessenkool wrote:
> > > PR target/92140: clang vs gcc optimizing with adc/sbb
> > > PR fortran/91926: assumed rank optional
> > > PR tree-optimization/91532: [SVE] Redundant predicated store in
> gcc.target/aarch64/fmla_2.c
> > > PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at
> tree-vect-stmts.c:1687
> > > PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction,
> at tree-vect-loop.c:4252
> > > PR c++/92015: internal compiler error: in cxx_eval_array_reference, at
> cp/constexpr.c:2568
> > > PR tree-optimization/92173: ICE in optab_for_tree_code, at
> optabs-tree.c:81
> > > PR tree-optimization/92173: ICE in optab_for_tree_code, at
> optabs-tree.c:81
> > > PR fortran/92174: runtime error: index 15 out of bounds for type
> 'gfc_expr *[15]
> > >
> > > Most of these aren't helpful at all, and none of these are good commit
> > > summaries.  The PR92173 one actually has identical commit messages btw,
> > > huh.  Ah, the second one (r277288) has the wrong changelog, but in the
> > > actual changelog file as well, not something any tool could fix up (or
> > > have we reached the singularity?)
> >
> > Identical commits are normally from where the same commit is made to
> > multiple branches.  It's not uncommon to see this when bugs are fixed.
>
> This is an actual mistake.  The commits are not identical at all, just
> the commit messages are (and the changelog entries, too).  Not something
> that happens to ften, but of course I hit it in the first random thing I
> pick :-)
>
> > Ultimately the question here is whether something like the above is more
> > or less useful than what we have today, which is summary lines of the
> form:
> >
> > <date> <user> <email>
>
> I already said I would prefer things like
>   Patch related to PR323
> as the patch subject lines.  No one argues that the current state of
> affairs is good.  I argue that replacing this with often wrong and
> irrelevant information isn't the best we can do.
>

How about using the first line that isn't a ChangeLog date/author line,
without trying to rewrite/augment it?

Jason

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 18/11/2019 20:53, Jason Merrill wrote:
> On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
> segher@kernel.crashing.org> wrote:
> 
>> On Mon, Nov 18, 2019 at 07:21:22PM +0000, Richard Earnshaw (lists) wrote:
>>> On 18/11/2019 18:53, Segher Boessenkool wrote:
>>>> PR target/92140: clang vs gcc optimizing with adc/sbb
>>>> PR fortran/91926: assumed rank optional
>>>> PR tree-optimization/91532: [SVE] Redundant predicated store in
>> gcc.target/aarch64/fmla_2.c
>>>> PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at
>> tree-vect-stmts.c:1687
>>>> PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction,
>> at tree-vect-loop.c:4252
>>>> PR c++/92015: internal compiler error: in cxx_eval_array_reference, at
>> cp/constexpr.c:2568
>>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
>> optabs-tree.c:81
>>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
>> optabs-tree.c:81
>>>> PR fortran/92174: runtime error: index 15 out of bounds for type
>> 'gfc_expr *[15]
>>>>
>>>> Most of these aren't helpful at all, and none of these are good commit
>>>> summaries.  The PR92173 one actually has identical commit messages btw,
>>>> huh.  Ah, the second one (r277288) has the wrong changelog, but in the
>>>> actual changelog file as well, not something any tool could fix up (or
>>>> have we reached the singularity?)
>>>
>>> Identical commits are normally from where the same commit is made to
>>> multiple branches.  It's not uncommon to see this when bugs are fixed.
>>
>> This is an actual mistake.  The commits are not identical at all, just
>> the commit messages are (and the changelog entries, too).  Not something
>> that happens to ften, but of course I hit it in the first random thing I
>> pick :-)
>>
>>> Ultimately the question here is whether something like the above is more
>>> or less useful than what we have today, which is summary lines of the
>> form:
>>>
>>> <date> <user> <email>
>>
>> I already said I would prefer things like
>>   Patch related to PR323
>> as the patch subject lines.  No one argues that the current state of
>> affairs is good.  I argue that replacing this with often wrong and
>> irrelevant information isn't the best we can do.
>>
> 
> How about using the first line that isn't a ChangeLog date/author line,
> without trying to rewrite/augment it?
> 
> Jason
> 

It would certainly be another way of doing it.  Sometimes it would
produce almost the same as an unadulterated PR; sometimes it would
produce something more meaningful and sometimes it would be pretty
useless.  It probably would hit more cases than my current script in
that it wouldn't require the commit to mention a PR in it.

The main problem is that the first line is often incomplete, and much of
it is also wasted with elements like the full path to a file that is
quite deep in the tree.  Lets take a quick example (the first I found in
the dump I have).

1998-12-17  Vladimir N. Makarov  <vmakarov@cygnus.com>
        * config/i60/i960.md (extendqihi2): Fix typo (usage ',' instead of
        ';').
1998-12-17  Michael Tiemann  <tiemann@axon.cygnus.com>
        * i960.md (extend*, zero_extend*): Don't generate rtl that looks
        like (subreg:SI (reg:SI N) 0), because it's wrong, and it hides
        optimizations from the combiner.

Firstly, this example misses a blank line between the author and the
change message itself, which makes distinguishing between this and the
multiple authors case harder.  Secondly, the entry really spans two
lines and cutting it off at the end of the first line would be, well a
bit odd.  We could try to piece things together more, by combining lines
until we find a sentence end ( \.$ or \.\s\s ), and we could also strip
off more of the path components to just leave the name of the file
committed.  For example,

i960.md (extendqihi2): Fix typo (usage ',' instead of ';').

That might work better, but obviously it's harder to handle and thus
more likely to create erroneous summaries.

In fact, the above currently just results in a summary of

[multiple commits]

because there are two authors mentioned with date stamps.

An advantage of this approach, of course, is that it would also work for
pre-egcs commits, to the extent that they have any useful commit message
at all.

The issue with bogus PR numbers will remain, of course, but that's no
worse than it is today.

R.

Re: Commit messages and the move to git

[Eric S. Raymond]

Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
> Well a lot of that is a property of the conversion tool.  git svn does a
> relatively poor job of anything other than straight history (I believe it
> just ignores the non-linear information.

Yes, svn-git does a *terrible* job on anything other than linear history.

That is a major reason I'm busting my hump to get the conversion done.
It would be very sad if you guys fell into using that.  It does a
tolerable job of live gatewaying on simple histories, but read this:

http://esr.ibiblio.org/?p=6778

>                                   I don't believe any tool can
> recreate information for cherry-picking unless it's recorded in the SVN
> meta-data.  Eric would be better placed to comment here.

You are correct, there is nothing practical that can be done in the absence
of svn:mergeinfo and svnmerge-integrated properties.

> My own observation is that when the SVN commits have merge meta-data,
> reposurgeon will pick this up and create links across to the relevant
> branches.  It does, however seem to create far more links than a traditional
> git merge would do, especially when a sequence of commits are referenced.  I
> don't know if that's essentially unfixable, or if it's something Eric
> intends to work on; but I've seen some cases where there are dozens of links
> back to a simple sequence of svn commits and where, I suspect, a single link
> back to the most recent of that sequence would be all that's really wanted.

First I have heard of this.

The intent of the present mergeinfo handing is that it looks for
mergeinfo declarations that are topologically equivalent to branch
merges (that is, they merge all revisions on a source branch rather
than cherry-picking isolated revisions) and rendering those as
gitspace merge links.  There is no attempt to create links
corresponding to Subversion cherry picks, as this does not fit
the Git DAG model.

I have cases that demonstrate this feature working in my test suite,
but they are relatively small and artificial. I would not describe
my mergeinfo handling as well-tested compared to the rest of the
analyzer, and I can thus easily believe your bug report.

What I need to troubleshoot this is a test case that is not trivial
but of a manageable size - over a couple hundred commits the volume
of diagnostics just overwhelms a Mark One Eyeball.  

Many of my test cases were trimmed to that size by doing stripping and
topological reduction on real repositories; I have a tool for this.
Do you have a real repository in mind I can start with?  The whole gcc
history is too huge, but if you were able to tell me that the bug is
exhibited within a few thousand commits of origin and point at where,
that I could work with.

An issue filed on the reposurgeon tracker would be appreciated.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> I think the main thing to make sure of in the conversion regarding that 
> issue is that cherry-picks do *not* turn into merge commits

I confirm that this is how it now works.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/11/2019 11:24, Eric S. Raymond wrote:
> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>> Well a lot of that is a property of the conversion tool.  git svn does a
>> relatively poor job of anything other than straight history (I believe it
>> just ignores the non-linear information.
> 
> Yes, svn-git does a *terrible* job on anything other than linear history.
> 
> That is a major reason I'm busting my hump to get the conversion done.
> It would be very sad if you guys fell into using that.  It does a
> tolerable job of live gatewaying on simple histories, but read this:
> 
> http://esr.ibiblio.org/?p=6778
> 
>>                                    I don't believe any tool can
>> recreate information for cherry-picking unless it's recorded in the SVN
>> meta-data.  Eric would be better placed to comment here.
> 
> You are correct, there is nothing practical that can be done in the absence
> of svn:mergeinfo and svnmerge-integrated properties.
> 
>> My own observation is that when the SVN commits have merge meta-data,
>> reposurgeon will pick this up and create links across to the relevant
>> branches.  It does, however seem to create far more links than a traditional
>> git merge would do, especially when a sequence of commits are referenced.  I
>> don't know if that's essentially unfixable, or if it's something Eric
>> intends to work on; but I've seen some cases where there are dozens of links
>> back to a simple sequence of svn commits and where, I suspect, a single link
>> back to the most recent of that sequence would be all that's really wanted.
> 
> First I have heard of this.
> 
> The intent of the present mergeinfo handing is that it looks for
> mergeinfo declarations that are topologically equivalent to branch
> merges (that is, they merge all revisions on a source branch rather
> than cherry-picking isolated revisions) and rendering those as
> gitspace merge links.  There is no attempt to create links
> corresponding to Subversion cherry picks, as this does not fit
> the Git DAG model.
> 
> I have cases that demonstrate this feature working in my test suite,
> but they are relatively small and artificial. I would not describe
> my mergeinfo handling as well-tested compared to the rest of the
> analyzer, and I can thus easily believe your bug report.
> 
> What I need to troubleshoot this is a test case that is not trivial
> but of a manageable size - over a couple hundred commits the volume
> of diagnostics just overwhelms a Mark One Eyeball.
> 
> Many of my test cases were trimmed to that size by doing stripping and
> topological reduction on real repositories; I have a tool for this.
> Do you have a real repository in mind I can start with?  The whole gcc
> history is too huge, but if you were able to tell me that the bug is
> exhibited within a few thousand commits of origin and point at where,
> that I could work with.
> 
> An issue filed on the reposurgeon tracker would be appreciated.
> 

I was looking at the reposurgeon code last night, and I think I can see 
what the problem *might* be, but I haven't had time to produce a testcase.

Some of our commits have mergeinfo that looks a bit like this:

202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421

which is a massive long list with a number of holes in it.

But I suspect the holes are really commits to other branches and that in 
the above describes a linear chain along one branch.  If so, rather than 
producing links to each subgroup (and perhaps dropping single non-list 
elements, the description can be mapped back to a contiguous sequence of 
commits down a branch and thus should really resolve to a single child 
being used for the merge source.  At present, I think for the above 
we're seeing a child reference created for each subrange in that list.

I'll see if I can construct a real testcase this evening.

Incidentally, the mergeinfo pass on the gcc repo is currently taking 
about 8 hours on my machine, that's 80-90% of the entire conversion 
time.  But it might be related to the above.

R.

Re: Commit messages and the move to git

[Jason Merrill]

On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) <
Richard.Earnshaw@arm.com> wrote:

> On 18/11/2019 20:53, Jason Merrill wrote:
> > On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
> > segher@kernel.crashing.org> wrote:
> >
> >> On Mon, Nov 18, 2019 at 07:21:22PM +0000, Richard Earnshaw (lists)
> wrote:
> >>> On 18/11/2019 18:53, Segher Boessenkool wrote:
> >>>> PR target/92140: clang vs gcc optimizing with adc/sbb
> >>>> PR fortran/91926: assumed rank optional
> >>>> PR tree-optimization/91532: [SVE] Redundant predicated store in
> >> gcc.target/aarch64/fmla_2.c
> >>>> PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at
> >> tree-vect-stmts.c:1687
> >>>> PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction,
> >> at tree-vect-loop.c:4252
> >>>> PR c++/92015: internal compiler error: in cxx_eval_array_reference, at
> >> cp/constexpr.c:2568
> >>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
> >> optabs-tree.c:81
> >>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
> >> optabs-tree.c:81
> >>>> PR fortran/92174: runtime error: index 15 out of bounds for type
> >> 'gfc_expr *[15]
> >>>>
> >>>> Most of these aren't helpful at all, and none of these are good commit
> >>>> summaries.  The PR92173 one actually has identical commit messages
> btw,
> >>>> huh.  Ah, the second one (r277288) has the wrong changelog, but in the
> >>>> actual changelog file as well, not something any tool could fix up (or
> >>>> have we reached the singularity?)
> >>>
> >>> Identical commits are normally from where the same commit is made to
> >>> multiple branches.  It's not uncommon to see this when bugs are fixed.
> >>
> >> This is an actual mistake.  The commits are not identical at all, just
> >> the commit messages are (and the changelog entries, too).  Not something
> >> that happens to ften, but of course I hit it in the first random thing I
> >> pick :-)
> >>
> >>> Ultimately the question here is whether something like the above is
> more
> >>> or less useful than what we have today, which is summary lines of the
> >> form:
> >>>
> >>> <date> <user> <email>
> >>
> >> I already said I would prefer things like
> >>   Patch related to PR323
> >> as the patch subject lines.  No one argues that the current state of
> >> affairs is good.  I argue that replacing this with often wrong and
> >> irrelevant information isn't the best we can do.
> >>
> >
> > How about using the first line that isn't a ChangeLog date/author line,
> > without trying to rewrite/augment it?
> >
> > Jason
> >
>
> It would certainly be another way of doing it.  Sometimes it would
> produce almost the same as an unadulterated PR; sometimes it would
> produce something more meaningful and sometimes it would be pretty
> useless.  It probably would hit more cases than my current script in
> that it wouldn't require the commit to mention a PR in it.
>
> The main problem is that the first line is often incomplete, and much of
> it is also wasted with elements like the full path to a file that is
> quite deep in the tree.  Lets take a quick example (the first I found in
> the dump I have).
>
> 1998-12-17  Vladimir N. Makarov  <vmakarov@cygnus.com>
>         * config/i60/i960.md (extendqihi2): Fix typo (usage ',' instead of
>         ';').
> 1998-12-17  Michael Tiemann  <tiemann@axon.cygnus.com>
>         * i960.md (extend*, zero_extend*): Don't generate rtl that looks
>         like (subreg:SI (reg:SI N) 0), because it's wrong, and it hides
>         optimizations from the combiner.
>
> Firstly, this example misses a blank line between the author and the
> change message itself, which makes distinguishing between this and the
> multiple authors case harder.  Secondly, the entry really spans two
> lines and cutting it off at the end of the first line would be, well a
> bit odd.  We could try to piece things together more, by combining lines
> until we find a sentence end ( \.$ or \.\s\s ), and we could also strip
> off more of the path components to just leave the name of the file
> committed.  For example,
>
> i960.md (extendqihi2): Fix typo (usage ',' instead of ';').
>
> That might work better, but obviously it's harder to handle and thus
> more likely to create erroneous summaries.
>

Yep. I don't think we need to worry about getting optimal one-line
summaries for ancient commits; something reasonably unique should be plenty.

Re: Commit messages and the move to git

[Segher Boessenkool]

On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> Yep. I don't think we need to worry about getting optimal one-line
> summaries for ancient commits; something reasonably unique should be plenty.

In that case, how about just "SVN rNNNNNN"?  And then we don't need the
footer from git-svn anymore either?  And don't need to mangle or wrangle
the commit message itself at all either.


Segher

Re: Commit messages and the move to git

[Jonathan Wakely]

On Tue, 19 Nov 2019 at 16:31, Segher Boessenkool wrote:
>
> On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> > Yep. I don't think we need to worry about getting optimal one-line
> > summaries for ancient commits; something reasonably unique should be plenty.
>
> In that case, how about just "SVN rNNNNNN"?

I was about to suggest the same thing.

Re: Commit messages and the move to git

[Jason Merrill]

On Tue, Nov 19, 2019 at 11:31 AM Segher Boessenkool <
segher@kernel.crashing.org> wrote:

> On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> > Yep. I don't think we need to worry about getting optimal one-line
> > summaries for ancient commits; something reasonably unique should be
> plenty.
>
> In that case, how about just "SVN rNNNNNN"?  And then we don't need the
> footer from git-svn anymore either?  And don't need to mangle or wrangle
> the commit message itself at all either.
>

Well, I was thinking of also giving some clue of what the commit was
about.  One possibly cut-off line accomplishes that, a simple revision
number not so much.

Jason

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/11/2019 16:31, Segher Boessenkool wrote:
> On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
>> Yep. I don't think we need to worry about getting optimal one-line
>> summaries for ancient commits; something reasonably unique should be plenty.
> 
> In that case, how about just "SVN rNNNNNN"?  And then we don't need the
> footer from git-svn anymore either?  And don't need to mangle or wrangle
> the commit message itself at all either.
> 
> 
> Segher
> 

Sorry, disagree.  That's as bad as just the author name, IMO.

R.

Re: Commit messages and the move to git

[Eric S. Raymond]

Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
> I was looking at the reposurgeon code last night, and I think I can see what
> the problem *might* be, but I haven't had time to produce a testcase.
> 
> Some of our commits have mergeinfo that looks a bit like this:
> 
> 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421
> 
> which is a massive long list with a number of holes in it.
> 
> But I suspect the holes are really commits to other branches and that in the
> above describes a linear chain along one branch.  If so, rather than
> producing links to each subgroup (and perhaps dropping single non-list
> elements, the description can be mapped back to a contiguous sequence of
> commits down a branch and thus should really resolve to a single child being
> used for the merge source.  At present, I think for the above we're seeing a
> child reference created for each subrange in that list.

I have no doubt you are correct. Detecting such interrupted ranges ia
foing to be...  interesting.

> Incidentally, the mergeinfo pass on the gcc repo is currently taking about 8
> hours on my machine, that's 80-90% of the entire conversion time.  But it
> might be related to the above.

You must be running the old Python code, there was on O(n**2) in that
phase that has since been fixed. Try the Go code from
https://gitlab.com/esr/reposurgeon; it is *much* faster.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Eric S. Raymond]

Jason Merrill <jason@redhat.com>:
> Well, I was thinking of also giving some clue of what the commit was
> about.  One possibly cut-off line accomplishes that, a simple revision
> number not so much.

It's conventional under Git to have comments lead with a summary sentence.

I think you're going to find that the value of Subversion revision references
fades pretty fast after the conversion. That has been my experience with
other conversions.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/11/2019 11:45, Richard Earnshaw (lists) wrote:
> On 19/11/2019 11:24, Eric S. Raymond wrote:
>> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>>> Well a lot of that is a property of the conversion tool.  git svn does a
>>> relatively poor job of anything other than straight history (I
>>> believe it
>>> just ignores the non-linear information.
>>
>> Yes, svn-git does a *terrible* job on anything other than linear history.
>>
>> That is a major reason I'm busting my hump to get the conversion done.
>> It would be very sad if you guys fell into using that.  It does a
>> tolerable job of live gatewaying on simple histories, but read this:
>>
>> http://esr.ibiblio.org/?p=6778
>>
>>>                                    I don't believe any tool can
>>> recreate information for cherry-picking unless it's recorded in the SVN
>>> meta-data.  Eric would be better placed to comment here.
>>
>> You are correct, there is nothing practical that can be done in the
>> absence
>> of svn:mergeinfo and svnmerge-integrated properties.
>>
>>> My own observation is that when the SVN commits have merge meta-data,
>>> reposurgeon will pick this up and create links across to the relevant
>>> branches.  It does, however seem to create far more links than a
>>> traditional
>>> git merge would do, especially when a sequence of commits are
>>> referenced.  I
>>> don't know if that's essentially unfixable, or if it's something Eric
>>> intends to work on; but I've seen some cases where there are dozens
>>> of links
>>> back to a simple sequence of svn commits and where, I suspect, a
>>> single link
>>> back to the most recent of that sequence would be all that's really
>>> wanted.
>>
>> First I have heard of this.
>>
>> The intent of the present mergeinfo handing is that it looks for
>> mergeinfo declarations that are topologically equivalent to branch
>> merges (that is, they merge all revisions on a source branch rather
>> than cherry-picking isolated revisions) and rendering those as
>> gitspace merge links.  There is no attempt to create links
>> corresponding to Subversion cherry picks, as this does not fit
>> the Git DAG model.
>>
>> I have cases that demonstrate this feature working in my test suite,
>> but they are relatively small and artificial. I would not describe
>> my mergeinfo handling as well-tested compared to the rest of the
>> analyzer, and I can thus easily believe your bug report.
>>
>> What I need to troubleshoot this is a test case that is not trivial
>> but of a manageable size - over a couple hundred commits the volume
>> of diagnostics just overwhelms a Mark One Eyeball.
>>
>> Many of my test cases were trimmed to that size by doing stripping and
>> topological reduction on real repositories; I have a tool for this.
>> Do you have a real repository in mind I can start with?  The whole gcc
>> history is too huge, but if you were able to tell me that the bug is
>> exhibited within a few thousand commits of origin and point at where,
>> that I could work with.
>>
>> An issue filed on the reposurgeon tracker would be appreciated.
>>
> 
> I was looking at the reposurgeon code last night, and I think I can see
> what the problem *might* be, but I haven't had time to produce a testcase.
> 
> Some of our commits have mergeinfo that looks a bit like this:
> 
> 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421
> 
> 
> which is a massive long list with a number of holes in it.
> 
> But I suspect the holes are really commits to other branches and that in
> the above describes a linear chain along one branch.  If so, rather than
> producing links to each subgroup (and perhaps dropping single non-list
> elements, the description can be mapped back to a contiguous sequence of
> commits down a branch and thus should really resolve to a single child
> being used for the merge source.  At present, I think for the above
> we're seeing a child reference created for each subrange in that list.
> 
> I'll see if I can construct a real testcase this evening.
> 
> Incidentally, the mergeinfo pass on the gcc repo is currently taking
> about 8 hours on my machine, that's 80-90% of the entire conversion
> time.  But it might be related to the above.
> 
> R.
> 

I've been unsuccessful so far in creating a simple reproducer.  However,
r278216 on the gcc 'ranger' branch is an example of what I mean.  The
property list for this is

$ svn propget svn:mergeinfo -r278216
FILE:///home/rearnsha/tmp/gcc-mirror/branches/ranger
/trunk:274955-274956,274958,274961-274962,274964,274966,274975-274976,274980-274988,274990-274992,274994,274996-275000,275004-275005,275007-275012,275021-275023,275025-275028,275030-275032,275034,275049-275050,275055,275059,275062-275063,275174,275177-275178,275187-275188,275190-275191,275195-275200,275204-275205,275210-275211,275223,275227,275231,275235-275240,275242-275243,275258,275260,275264-275271,275274,275284-275285,275290-275293,275295,275297-275299,275303,275313-275316,275318,275320,275322,275324,275328-275338,275341-275344,275352-275358,275362,275364-275365,275367-275369,275376-275377,275387-275391,275395-275404,275406,275408-275409,275411,275414,275421,275426,275442,275444,275449-275450,275452-275458,275460,275462,275464,275472-275473,275475-275478,275482-275484,275486,275488-275489,275493,275497,275501-275508,275513-275514,275517-275518,275521-275522,275524-275537,275539-275541,275544,275551,275555,275557-275589,275591-275594,275597-275606,275608,275611,275613,275617,275622,275631-275635,275639-275644,275648,275650-275652,275655,275657,275667,275680,275682-275683,275685,275689,275691,275695-275704,275709,275713,275717-275719,275723,275726-275727,275729-275731,275735-275736,275741,275743-275755,275757-275759,275763,275768-275800,275802-275809,275813-275814,275833,275836-275875,275896-275899,275901,275905-275907,275919,275924-275926,275928,275930-275972,275976-275979,275981-275982,275986,275989-275990,275992,275994,275996,275998-275999,276001-276002,276004,276006-276007,276011,276015,276017-276022,276026-276027,276030,276035-276036,276041,276045-276059,276063-276065,276085,276089,276091-276100,276102-276103,276105-276107,276111-276112,276119-276123,276125,276127-276128,276132-276135,276139-276159,276162-276168,276172-276180,276183-276184,276186-276188,276190-276193,276196,276211-276213,276227-276228,276236,276240,276244,276248-276249,276251,276253-276256,276260,276264-276272,276276,276294-276341,276343,276359-276361,276371-276376,276380,276382,276386-276389,276391-276396,276401-276405,276407-276411,276415-276418,276420,276422,276424,276426-276434,276438-276449,276452-276457,276459,276461-276466,276468-276474,276479,276484,276487-276489,276491-276498,276502-276508,276510,276515-276516,276518-276519,276525,276527,276530,276532,276539,276542-276543,276555-276556,276560-276564,276566-276568,276571-276572,276574-276577,276579-276582,276584-276585,276587-276597,276600-276603,276605,276618,276621-276624,276626-276627,276629-276630,276634-276640,276644-276645,276648-276651,276653-276655,276657-276661,276663-276665,276668,276670-276671,276674-276675,276679-276681,276685-276686,276688-276695,276698,276700,276702-276703,276705-276709,276711,276721-276722,276725,276750-276758,276760,276762-276764,276766-276768,276770-276771,276773,276786-276787,276789-276792,276796,276804,276807-276824,276826-276836,276839-276843,276846-276851,276854,276858-276861,276864-276866,276870-276876,276878,276882,276885-276892,276894,276896-276903,276906-276908,276912-276916,276920-276926,276928,276933-276943,276947-276956,276958-276964,276967-276972,276976-276978,276982-277000,277005,277008-277011,277015,277023,277033,277049,277054,277056-277063,277065,277067-277068,277070-277071,277073,277076,277080,277082-277084,277088-277103,277105,277107-277108,277110-277115,277120-277121,277126,277128-277130,277133-277135,277140-277143,277150-277151,277153,277155-277158,277164-277192,277194,277199-277205,277209-277211,277214-277217,277221,277223-277241,277260-277262,277264,277266-277268,277270-277271,277276-277293,277297,277299-277302,277306-277311,277313-277314,277320-277323,277333,277335-277349,277351-277352,277358,277362-277363,277365-277369,277371-277375,277394-277395,277403-277404,277406-277410,277415-277416,277419,277421,277424-277427,277433-277438,277440-277442,277446,277448-277451,277455,277458-277459,277462,277468-277470,277472,277475-277476,277480-277487,277491-277492,277499,277501-277504,277507-277510,277512-277514,277516-277517,277524-277525,277527,277533-277535,277537,277544-277546,277550-277569,277571-277573,277575-277579,277588-277589,277591-277593,277595,277599-277607,277609-277610,277612-277624,277627-277637,277639,277643,277648-277649,277653-277664,277666-277667,277672,277674-277686,277697-277699,277703-277709,277711,277714-277715,277719,277723,277728,277730,277732-277735,277740-277743,277749,277752-277760,277764,277766-277769,277771-277780,277782,277784-277799,277801,277810,277812-277824,277826-277839,277845-277854,277859-277866,277870-277873,277875-277893,277895,277899-277936,277940-277956,277958-277966,277969,277972-277979,277990-277991,277993-277995,277999-278000,278003-278009,278013,278016-278017,278019-278028,278032-278035,278038,278041,278044-278049,278051,278053-278058,278062,278064-278066,278068-278070,278074-278091,278093-278096,278098-278107,278111-278129,278131-278142,278144-278153,278156-278157,278159,278179,278184-278185,278189-278196,278199-278200

and in the conversion we get about 35 links back to different revisions
in trunk.

I don't know if the SHA codes are stable, but in my conversion, done
last night, it comes out at 44b84e63a8b00b9881fbb93d3af1536c2338aa72

There's another example at r277770 on the same branch, which has even
more links.

R.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/11/2019 19:32, Eric S. Raymond wrote:
> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>> I was looking at the reposurgeon code last night, and I think I can see what
>> the problem *might* be, but I haven't had time to produce a testcase.
>>
>> Some of our commits have mergeinfo that looks a bit like this:
>>
>> 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421
>>
>> which is a massive long list with a number of holes in it.
>>
>> But I suspect the holes are really commits to other branches and that in the
>> above describes a linear chain along one branch.  If so, rather than
>> producing links to each subgroup (and perhaps dropping single non-list
>> elements, the description can be mapped back to a contiguous sequence of
>> commits down a branch and thus should really resolve to a single child being
>> used for the merge source.  At present, I think for the above we're seeing a
>> child reference created for each subrange in that list.
> 
> I have no doubt you are correct. Detecting such interrupted ranges ia
> foing to be...  interesting.
> 
>> Incidentally, the mergeinfo pass on the gcc repo is currently taking about 8
>> hours on my machine, that's 80-90% of the entire conversion time.  But it
>> might be related to the above.
> 
> You must be running the old Python code, there was on O(n**2) in that
> phase that has since been fixed. Try the Go code from
> https://gitlab.com/esr/reposurgeon; it is *much* faster.
> 

Nope, that was from running the go version from yesterday.  This one, to
be precise:  1ab3c514c6cd5e1a5d6b68a8224df299751ca637

This pass used to be very fast a couple of weeks back, but something
went in recently that's caused a major slowdown.

Oh, and I've been having problems with the ChangeLogs command as well.
It used to run fine on my machine (128G), but now it's started blowing
memory and taking my X server down.

R.

R.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/11/2019 19:47, Richard Earnshaw (lists) wrote:
> On 19/11/2019 19:32, Eric S. Raymond wrote:
>> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>>> I was looking at the reposurgeon code last night, and I think I can see what
>>> the problem *might* be, but I haven't had time to produce a testcase.
>>>
>>> Some of our commits have mergeinfo that looks a bit like this:
>>>
>>> 202022-202023,202026,202028-202029,202036,202039-202041,202043-202044,202048-202049,202051-202056,202058-202061,202064-202065,202068-202071,202077,202079-202082,202084,202086-202088,202092-202104,202106-202113,202115-202119,202121,202124-202134,202139,202142-202146,202148-202150,202153-202154,202158-202159,202163-202165,202168,202172,202174,202179-202180,202184-202192,202195,202197,202202-202208,202225-202230,202232-202233,202237-202239,202242,202244-202245,202247,202250-202251,202258-202264,202266,202269,202271-202275,202279,202281-202282,202284,202286,202289-202292,202296-202299,202301-202302,202305,202309,202311-202323,202327-202335,202337,202339,202343-202346,202350,202352,202356-202357,202359-202360,202363-202371,202373-202374,202377,202379-202382,202384,202389,202391-202395,202398-202407,202409,202411,202416-202418,202421
>>>
>>> which is a massive long list with a number of holes in it.
>>>
>>> But I suspect the holes are really commits to other branches and that in the
>>> above describes a linear chain along one branch.  If so, rather than
>>> producing links to each subgroup (and perhaps dropping single non-list
>>> elements, the description can be mapped back to a contiguous sequence of
>>> commits down a branch and thus should really resolve to a single child being
>>> used for the merge source.  At present, I think for the above we're seeing a
>>> child reference created for each subrange in that list.
>>
>> I have no doubt you are correct. Detecting such interrupted ranges ia
>> foing to be...  interesting.
>>
>>> Incidentally, the mergeinfo pass on the gcc repo is currently taking about 8
>>> hours on my machine, that's 80-90% of the entire conversion time.  But it
>>> might be related to the above.
>>
>> You must be running the old Python code, there was on O(n**2) in that
>> phase that has since been fixed. Try the Go code from
>> https://gitlab.com/esr/reposurgeon; it is *much* faster.
>>
> 
> Nope, that was from running the go version from yesterday.  This one, to
> be precise:  1ab3c514c6cd5e1a5d6b68a8224df299751ca637
> 
> This pass used to be very fast a couple of weeks back, but something
> went in recently that's caused a major slowdown.
> 
> Oh, and I've been having problems with the ChangeLogs command as well.
> It used to run fine on my machine (128G), but now it's started blowing
> memory and taking my X server down.
> 
> R.
> 
> R.
> 


Here's the stats output:

# Statistics on read and processing times
timing
        commits:        276738  (from 278380)
        parsing:        2.85%   14m22.861991058s
       cleaning:        0.32%   1m37.653100823s
       filemaps:        0.37%   1m52.851558995s
        commits:        4.40%   22m15.380157228s
     rootcommit:        0.00%   8.779µs
       branches:        0.04%   12.710113776s
        parents:        0.00%   121.73484ms
           root:        0.00%   267.997µs
    branchlinks:        0.00%   10.58361ms
      mergeinfo:        91.67%  7h43m15.416510183s
       branches:        0.00%   11.616µs
         dejunk:        0.04%   10.672889443s
      polishing:        0.04%   11.249533399s
      tagifying:        0.03%   10.528735532s
    tagcleaning:        0.03%   9.880052536s
     debubbling:        0.00%   1.384357053s
    renumbering:        0.20%   59.718288526s
          total:        9/sec   8h25m20.439895394s

Re: Commit messages and the move to git

[Eric S. Raymond]

Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
> I've been unsuccessful so far in creating a simple reproducer.  However,
> r278216 on the gcc 'ranger' branch is an example of what I mean.  The
> property list for this is
> 
> $ svn propget svn:mergeinfo -r278216
> FILE:///home/rearnsha/tmp/gcc-mirror/branches/ranger
> /trunk:274955-274956,274958,274961-274962,274964,274966,274975-274976,274980-274988,274990-274992,274994,274996-275000,275004-275005,275007-275012,275021-275023,275025-275028,275030-275032,275034,275049-275050,275055,275059,275062-275063,275174,275177-275178,275187-275188,275190-275191,275195-275200,275204-275205,275210-275211,275223,275227,275231,275235-275240,275242-275243,275258,275260,275264-275271,275274,275284-275285,275290-275293,275295,275297-275299,275303,275313-275316,275318,275320,275322,275324,275328-275338,275341-275344,275352-275358,275362,275364-275365,275367-275369,275376-275377,275387-275391,275395-275404,275406,275408-275409,275411,275414,275421,275426,275442,275444,275449-275450,275452-275458,275460,275462,275464,275472-275473,275475-275478,275482-275484,275486,275488-275489,275493,275497,275501-275508,275513-275514,275517-275518,275521-275522,275524-275537,275539-275541,275544,275551,275555,275557-275589,275591-275594,275597-275606,275608,275611,275613,275617,275622,275631-275635,275639-275644,275648,275650-275652,275655,275657,275667,275680,275682-275683,275685,275689,275691,275695-275704,275709,275713,275717-275719,275723,275726-275727,275729-275731,275735-275736,275741,275743-275755,275757-275759,275763,275768-275800,275802-275809,275813-275814,275833,275836-275875,275896-275899,275901,275905-275907,275919,275924-275926,275928,275930-275972,275976-275979,275981-275982,275986,275989-275990,275992,275994,275996,275998-275999,276001-276002,276004,276006-276007,276011,276015,276017-276022,276026-276027,276030,276035-276036,276041,276045-276059,276063-276065,276085,276089,276091-276100,276102-276103,276105-276107,276111-276112,276119-276123,276125,276127-276128,276132-276135,276139-276159,276162-276168,276172-276180,276183-276184,276186-276188,276190-276193,276196,276211-276213,276227-276228,276236,276240,276244,276248-276249,276251,276253-276256,276260,276264-276272,276276,276294-276341,276343,276359-276361,276371-276376,276380,276382,276386-276389,276391-276396,276401-276405,276407-276411,276415-276418,276420,276422,276424,276426-276434,276438-276449,276452-276457,276459,276461-276466,276468-276474,276479,276484,276487-276489,276491-276498,276502-276508,276510,276515-276516,276518-276519,276525,276527,276530,276532,276539,276542-276543,276555-276556,276560-276564,276566-276568,276571-276572,276574-276577,276579-276582,276584-276585,276587-276597,276600-276603,276605,276618,276621-276624,276626-276627,276629-276630,276634-276640,276644-276645,276648-276651,276653-276655,276657-276661,276663-276665,276668,276670-276671,276674-276675,276679-276681,276685-276686,276688-276695,276698,276700,276702-276703,276705-276709,276711,276721-276722,276725,276750-276758,276760,276762-276764,276766-276768,276770-276771,276773,276786-276787,276789-276792,276796,276804,276807-276824,276826-276836,276839-276843,276846-276851,276854,276858-276861,276864-276866,276870-276876,276878,276882,276885-276892,276894,276896-276903,276906-276908,276912-276916,276920-276926,276928,276933-276943,276947-276956,276958-276964,276967-276972,276976-276978,276982-277000,277005,277008-277011,277015,277023,277033,277049,277054,277056-277063,277065,277067-277068,277070-277071,277073,277076,277080,277082-277084,277088-277103,277105,277107-277108,277110-277115,277120-277121,277126,277128-277130,277133-277135,277140-277143,277150-277151,277153,277155-277158,277164-277192,277194,277199-277205,277209-277211,277214-277217,277221,277223-277241,277260-277262,277264,277266-277268,277270-277271,277276-277293,277297,277299-277302,277306-277311,277313-277314,277320-277323,277333,277335-277349,277351-277352,277358,277362-277363,277365-277369,277371-277375,277394-277395,277403-277404,277406-277410,277415-277416,277419,277421,277424-277427,277433-277438,277440-277442,277446,277448-277451,277455,277458-277459,277462,277468-277470,277472,277475-277476,277480-277487,277491-277492,277499,277501-277504,277507-277510,277512-277514,277516-277517,277524-277525,277527,277533-277535,277537,277544-277546,277550-277569,277571-277573,277575-277579,277588-277589,277591-277593,277595,277599-277607,277609-277610,277612-277624,277627-277637,277639,277643,277648-277649,277653-277664,277666-277667,277672,277674-277686,277697-277699,277703-277709,277711,277714-277715,277719,277723,277728,277730,277732-277735,277740-277743,277749,277752-277760,277764,277766-277769,277771-277780,277782,277784-277799,277801,277810,277812-277824,277826-277839,277845-277854,277859-277866,277870-277873,277875-277893,277895,277899-277936,277940-277956,277958-277966,277969,277972-277979,277990-277991,277993-277995,277999-278000,278003-278009,278013,278016-278017,278019-278028,278032-278035,278038,278041,278044-278049,278051,278053-278058,278062,278064-278066,278068-278070,278074-278091,278093-278096,278098-278107,278111-278129,278131-278142,278144-278153,278156-278157,278159,278179,278184-278185,278189-278196,278199-278200
> 
> and in the conversion we get about 35 links back to different revisions
> in trunk.
> 
> I don't know if the SHA codes are stable, but in my conversion, done
> last night, it comes out at 44b84e63a8b00b9881fbb93d3af1536c2338aa72
> 
> There's another example at r277770 on the same branch, which has even
> more links.
> 
> R.

File an issue here, please.

https://gitlab.com/esr/reposurgeon/issues
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Eric S. Raymond]

Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
> Nope, that was from running the go version from yesterday.  This one, to
> be precise:  1ab3c514c6cd5e1a5d6b68a8224df299751ca637
> 
> This pass used to be very fast a couple of weeks back, but something
> went in recently that's caused a major slowdown.
> 
> Oh, and I've been having problems with the ChangeLogs command as well.
> It used to run fine on my machine (128G), but now it's started blowing
> memory and taking my X server down.

That sucks.  Those were stretches of code the two guys working with me
have been trying to speed up. Looks like that backfired.

Please file isses at  https://gitlab.com/esr/reposurgeon/issues and
include timing reports if you can.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/11/2019 22:14, Eric S. Raymond wrote:
> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>> Nope, that was from running the go version from yesterday.  This one, to
>> be precise:  1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>>
>> This pass used to be very fast a couple of weeks back, but something
>> went in recently that's caused a major slowdown.
>>
>> Oh, and I've been having problems with the ChangeLogs command as well.
>> It used to run fine on my machine (128G), but now it's started blowing
>> memory and taking my X server down.
> 
> That sucks.  Those were stretches of code the two guys working with me
> have been trying to speed up. Looks like that backfired.
> 
> Please file isses at  https://gitlab.com/esr/reposurgeon/issues and
> include timing reports if you can.
> 
OK

I'll see if I can narrow the offending commit down a bit first.  I have
a rough idea when each occurred, but I haven't pinpointed a precise commit.

R.

Re: Commit messages and the move to git

[Segher Boessenkool]

On Tue, Nov 19, 2019 at 02:36:21PM -0500, Eric S. Raymond wrote:
> Jason Merrill <jason@redhat.com>:
> > Well, I was thinking of also giving some clue of what the commit was
> > about.  One possibly cut-off line accomplishes that, a simple revision
> > number not so much.

Sure, but it isn't easy at all to automatically come up with anything
useful or close to correct.  But if you start the subject line with the
SVN revision number, it is very useful.

> It's conventional under Git to have comments lead with a summary sentence.
> 
> I think you're going to find that the value of Subversion revision references
> fades pretty fast after the conversion. That has been my experience with
> other conversions.

Bugzilla is filled to the brim with SVN revision numbers.  This won't
lose relevance any time soon.  Decades of history.

Most of the time after I type "git log" I type "/\<123456\>".  We need
to keep a way to easily map SVN revision ids to git commits, and
something a bit more elegant than the ugly git-svn footers would be nice.


Segher

Re: Commit messages and the move to git

[Joseph Myers]

On Tue, 19 Nov 2019, Segher Boessenkool wrote:

> Most of the time after I type "git log" I type "/\<123456\>".  We need
> to keep a way to easily map SVN revision ids to git commits, and
> something a bit more elegant than the ugly git-svn footers would be nice.

Whatever reposurgeon's "write --legacy" yield seems appropriate for making 
the SVN revision ids readily available in the commit messages.  I don't 
think the summary line is a good place for that information.

I do think "Related to PR NNNNN (description)" or similar is a good 
summary line to insert where the present summary line is just a ChangeLog 
date/author line.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Nicholas Krause]

On 11/19/19 6:44 PM, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Segher Boessenkool wrote:
>
>> Most of the time after I type "git log" I type "/\<123456\>".  We need
>> to keep a way to easily map SVN revision ids to git commits, and
>> something a bit more elegant than the ugly git-svn footers would be nice.
> Whatever reposurgeon's "write --legacy" yield seems appropriate for making
> the SVN revision ids readily available in the commit messages.  I don't
> think the summary line is a good place for that information.
>
> I do think "Related to PR NNNNN (description)" or similar is a good
> summary line to insert where the present summary line is just a ChangeLog
> date/author line.
Sorry for pointing this out if it was not obvious but Related to PR NNNNN or
commit id in the message is fine. You would have to figure out whether the
git id is more important or the PR for each commit as normally only one
of these is used.

Normally in my experience git bisect or revert use ids directly but 
everything
else can just use the ported svn or PR from Bugzilla. It really depends 
but the
ids are more for if your dealing with the projects history itself rather 
than  just
a bug on the bugzilla.

That's just my opinion through so take it wait a grain of salt,
Nick
>

Re: Commit messages and the move to git

[Jonathan Wakely]

On Tue, 19 Nov 2019 at 23:52, Nicholas Krause wrote:
>
>
>
> On 11/19/19 6:44 PM, Joseph Myers wrote:
> > On Tue, 19 Nov 2019, Segher Boessenkool wrote:
> >
> >> Most of the time after I type "git log" I type "/\<123456\>".  We need
> >> to keep a way to easily map SVN revision ids to git commits, and
> >> something a bit more elegant than the ugly git-svn footers would be nice.
> > Whatever reposurgeon's "write --legacy" yield seems appropriate for making
> > the SVN revision ids readily available in the commit messages.  I don't
> > think the summary line is a good place for that information.
> >
> > I do think "Related to PR NNNNN (description)" or similar is a good
> > summary line to insert where the present summary line is just a ChangeLog
> > date/author line.
> Sorry for pointing this out if it was not obvious but Related to PR NNNNN or
> commit id in the message is fine. You would have to figure out whether the
> git id is more important or the PR for each commit as normally only one
> of these is used.

What git ID though? Not all patches are fixing regressions or bugs
introduced by other patches, and even if they are, figuring out the ID
of the commit that introduced the bug by scraping Bugzilla comments is
not practical. If the existing svn commit log mentions a PR number
then that's easy to use, there's no need to complicate it.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Tue, 19 Nov 2019 at 23:29, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Tue, Nov 19, 2019 at 02:36:21PM -0500, Eric S. Raymond wrote:
> > Jason Merrill <jason@redhat.com>:
> > > Well, I was thinking of also giving some clue of what the commit was
> > > about.  One possibly cut-off line accomplishes that, a simple revision
> > > number not so much.
>
> Sure, but it isn't easy at all to automatically come up with anything
> useful or close to correct.  But if you start the subject line with the
> SVN revision number, it is very useful.
>
> > It's conventional under Git to have comments lead with a summary sentence.
> >
> > I think you're going to find that the value of Subversion revision references
> > fades pretty fast after the conversion. That has been my experience with
> > other conversions.
>
> Bugzilla is filled to the brim with SVN revision numbers.  This won't
> lose relevance any time soon.  Decades of history.
>
> Most of the time after I type "git log" I type "/\<123456\>".  We need
> to keep a way to easily map SVN revision ids to git commits, and

As a aside, I use these aliases often with the current git-svn repo:

$ git help srev
'srev' is aliased to 'svn log --show-commit --oneline -r'
$ git srev 276968
r276968 | aa45db50a03 |         PR c++/91930 - ICE with constrained
inherited default ctor.

$ git help sshow
'sshow' is aliased to '!f(){ git srev ${1#r} | awk -F '|'
'/^r[[:digit:]]/ {if (length($2)) print $2}' | xargs --no-run-if-empty
git show ; }; f'

These won't work once we move to Git though.

Re: Commit messages and the move to git

[Segher Boessenkool]

On Wed, Nov 20, 2019 at 08:58:05AM +0000, Jonathan Wakely wrote:
> > Most of the time after I type "git log" I type "/\<123456\>".  We need
> > to keep a way to easily map SVN revision ids to git commits, and
> 
> As a aside, I use these aliases often with the current git-svn repo:
> 
> $ git help srev
> 'srev' is aliased to 'svn log --show-commit --oneline -r'
> $ git srev 276968
> r276968 | aa45db50a03 |         PR c++/91930 - ICE with constrained
> inherited default ctor.

Handy, but:

svn: E155007: '/home/segher/src/gcc' is not a working copy

I won't set up git-svn in my main work space, that would cause all kinds
of problems (not in the least that it encourages accidents) -- it's not
necessarily a great idea to have two-headed monsters in your living room.

> $ git help sshow
> 'sshow' is aliased to '!f(){ git srev ${1#r} | awk -F '|'
> '/^r[[:digit:]]/ {if (length($2)) print $2}' | xargs --no-run-if-empty
> git show ; }; f'
> 
> These won't work once we move to Git though.

It would be good if whatever convention we do for commit messages and
their first line would be machine parseable as well.


Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 20/11/2019 11:27, Segher Boessenkool wrote:
> On Wed, Nov 20, 2019 at 08:58:05AM +0000, Jonathan Wakely wrote:
>>> Most of the time after I type "git log" I type "/\<123456\>".  We need
>>> to keep a way to easily map SVN revision ids to git commits, and
>>
>> As a aside, I use these aliases often with the current git-svn repo:
>>
>> $ git help srev
>> 'srev' is aliased to 'svn log --show-commit --oneline -r'
>> $ git srev 276968
>> r276968 | aa45db50a03 |         PR c++/91930 - ICE with constrained
>> inherited default ctor.
> 
> Handy, but:
> 
> svn: E155007: '/home/segher/src/gcc' is not a working copy
> 
> I won't set up git-svn in my main work space, that would cause all kinds
> of problems (not in the least that it encourages accidents) -- it's not
> necessarily a great idea to have two-headed monsters in your living room.
> 
>> $ git help sshow
>> 'sshow' is aliased to '!f(){ git srev ${1#r} | awk -F '|'
>> '/^r[[:digit:]]/ {if (length($2)) print $2}' | xargs --no-run-if-empty
>> git show ; }; f'
>>
>> These won't work once we move to Git though.
> 
> It would be good if whatever convention we do for commit messages and
> their first line would be machine parseable as well.
> 

I think that would be pretty pointless.  We're not going to have machine 
parsable summaries going forwards, so why would it really help for 
historical commits?

R.

Re: Commit messages and the move to git

[Segher Boessenkool]

On Wed, Nov 20, 2019 at 11:30:36AM +0000, Richard Earnshaw (lists) wrote:
> On 20/11/2019 11:27, Segher Boessenkool wrote:
> >On Wed, Nov 20, 2019 at 08:58:05AM +0000, Jonathan Wakely wrote:
> >>These won't work once we move to Git though.
> >
> >It would be good if whatever convention we do for commit messages and
> >their first line would be machine parseable as well.
> 
> I think that would be pretty pointless.  We're not going to have machine 
> parsable summaries going forwards, so why would it really help for 
> historical commits?

There are give or take 173300 SVN commits on trunk alone.  And we have
references to SVN revision numbers everywhere (mailing list mails,
bugzilla PRs, etc.)


Segher

Re: Commit messages and the move to git

[Jason Merrill]

On Wed, Nov 20, 2019 at 6:27 AM Segher Boessenkool <
segher@kernel.crashing.org> wrote:

> It would be good if whatever convention we do for commit messages and
> their first line would be machine parseable as well.
>

The first line should be useful to humans, machines can parse the whole
message.

Jason

Re: Commit messages and the move to git

[Szabolcs Nagy]

On 19/11/2019 23:44, Joseph Myers wrote:
> I do think "Related to PR NNNNN (description)" or similar is a good 
> summary line to insert where the present summary line is just a ChangeLog 
> date/author line.

i agree.

Re: Commit messages and the move to git

[Segher Boessenkool]

On Wed, Nov 20, 2019 at 09:25:19AM -0500, Jason Merrill wrote:
> On Wed, Nov 20, 2019 at 6:27 AM Segher Boessenkool <
> segher@kernel.crashing.org> wrote:
> 
> > It would be good if whatever convention we do for commit messages and
> > their first line would be machine parseable as well.
> 
> The first line should be useful to humans, machines can parse the whole
> message.

Yeah, agreed.  And thinking more about this made me think it would work
best to use some to-the-side database for this...  Just a grep or similar,
on some text file you need to prepare once after the conversion.  This
also is much faster than grepping git output :-)

So we are back to having a very guesswork subject for very many commits.


Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/11/2019 23:44, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Segher Boessenkool wrote:
> 
>> Most of the time after I type "git log" I type "/\<123456\>".  We need
>> to keep a way to easily map SVN revision ids to git commits, and
>> something a bit more elegant than the ugly git-svn footers would be nice.
> 
> Whatever reposurgeon's "write --legacy" yield seems appropriate for making 
> the SVN revision ids readily available in the commit messages.  I don't 
> think the summary line is a good place for that information.
> 
> I do think "Related to PR NNNNN (description)" or similar is a good 
> summary line to insert where the present summary line is just a ChangeLog 
> date/author line.
> 

If we go that route, then there's a bit of auditing to do, because a
fair number of commits have simple typos in the pr numbers.  I can
produce a list of the most likely sources of error (there are about 550
from 40000 rewrites) that need looking at, but checking them all myself
would be very tedious.  Best would be to split the list up and divide
and conquer the checking across a few developers.

I think we'd just have to accept that manually checking all 40000
rewrites is impractical, so only those thrown up as suspicious can
really be checked this way (on checks I've made so far, only about 10%
of the highlighted cases are really wrong).

R.

Re: Commit messages and the move to git

[Joseph Myers]

On Tue, 19 Nov 2019, Eric S. Raymond wrote:

> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
> > Nope, that was from running the go version from yesterday.  This one, to
> > be precise:  1ab3c514c6cd5e1a5d6b68a8224df299751ca637
> > 
> > This pass used to be very fast a couple of weeks back, but something
> > went in recently that's caused a major slowdown.
> > 
> > Oh, and I've been having problems with the ChangeLogs command as well.
> > It used to run fine on my machine (128G), but now it's started blowing
> > memory and taking my X server down.
> 
> That sucks.  Those were stretches of code the two guys working with me
> have been trying to speed up. Looks like that backfired.
> 
> Please file isses at  https://gitlab.com/esr/reposurgeon/issues and
> include timing reports if you can.

I see the changelogs issue is fixed (I can run a conversion past that 
point on a system with 128GB memory, with mergeinfo processing being very 
slow as described by Richard).  But then I get errors:

*** Unknown syntax: relax

followed by the "tag /branch-root|branchpoint/ delete" command giving an 
error

reposurgeon: assignments invalidated by GC

and a "script abort" in conversion.log, after which it starts writing out 
gcc.fi (I think without processing any of the rest of gcc.lift).  I don't 
know whether the above errors are bugs in reposurgeon or in the 
gcc-conversion scripts.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 21/11/2019 16:40, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Eric S. Raymond wrote:
> 
>> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>>> Nope, that was from running the go version from yesterday.  This one, to
>>> be precise:  1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>>>
>>> This pass used to be very fast a couple of weeks back, but something
>>> went in recently that's caused a major slowdown.
>>>
>>> Oh, and I've been having problems with the ChangeLogs command as well.
>>> It used to run fine on my machine (128G), but now it's started blowing
>>> memory and taking my X server down.
>>
>> That sucks.  Those were stretches of code the two guys working with me
>> have been trying to speed up. Looks like that backfired.
>>
>> Please file isses at  https://gitlab.com/esr/reposurgeon/issues and
>> include timing reports if you can.
> 
> I see the changelogs issue is fixed (I can run a conversion past that
> point on a system with 128GB memory, with mergeinfo processing being very
> slow as described by Richard).  

This is
https://gitlab.com/esr/reposurgeon/issues/153

> But then I get errors:
> 
> *** Unknown syntax: relax
> 

Change that to

set relax

> followed by the "tag /branch-root|branchpoint/ delete" command giving an
> error
> 
> reposurgeon: assignments invalidated by GC
> 
> and a "script abort" in conversion.log, after which it starts writing out
> gcc.fi (I think without processing any of the rest of gcc.lift).  I don't
> know whether the above errors are bugs in reposurgeon or in the
> gcc-conversion scripts.
> 

Re: Commit messages and the move to git

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> I see the changelogs issue is fixed (I can run a conversion past that 
> point on a system with 128GB memory, with mergeinfo processing being very 
> slow as described by Richard).  But then I get errors:
> 
> *** Unknown syntax: relax

Missing "relax" command probably means your reposurgeon is very old.
What does "version" say?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Eric S. Raymond]

Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
> > But then I get errors:
> > 
> > *** Unknown syntax: relax
> > 
> 
> Change that to
> 
> set relax

Oops.  He's right.  It used to be a command, but that changed recently
as art of a redesign of log levels and options.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 21/11/2019 16:40, Joseph Myers wrote:
> On Tue, 19 Nov 2019, Eric S. Raymond wrote:
> 
>> Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
>> > Nope, that was from running the go version from yesterday.  This one, to
>> > be precise:  1ab3c514c6cd5e1a5d6b68a8224df299751ca637
>> > 
>> > This pass used to be very fast a couple of weeks back, but something
>> > went in recently that's caused a major slowdown.
>> > 
>> > Oh, and I've been having problems with the ChangeLogs command as well.
>> > It used to run fine on my machine (128G), but now it's started blowing
>> > memory and taking my X server down.
>> 
>> That sucks.  Those were stretches of code the two guys working with me
>> have been trying to speed up. Looks like that backfired.
>> 
>> Please file isses at  https://gitlab.com/esr/reposurgeon/issues and
>> include timing reports if you can.
> 
> I see the changelogs issue is fixed (I can run a conversion past that
> point on a system with 128GB memory, with mergeinfo processing being very
> slow as described by Richard).  But then I get errors:
> 

Eric, now that the changelogs command can take a selection set, do you
have a suggestion for how we might construct a sets that are just the
merge commands, or just the copies?  Both of these seem to get the wrong
author attribution and it would be nice to exclude them.

R.

> *** Unknown syntax: relax
> 
> followed by the "tag /branch-root|branchpoint/ delete" command giving an
> error
> 
> reposurgeon: assignments invalidated by GC
> 
> and a "script abort" in conversion.log, after which it starts writing out
> gcc.fi (I think without processing any of the rest of gcc.lift).  I don't
> know whether the above errors are bugs in reposurgeon or in the
> gcc-conversion scripts.
> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.com

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

[-- Attachment #1: Type: text/plain, Size: 6943 bytes --]

On 19/11/2019 14:56, Jason Merrill wrote:
> On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) <
> Richard.Earnshaw@arm.com> wrote:
> 
>> On 18/11/2019 20:53, Jason Merrill wrote:
>>> On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
>>> segher@kernel.crashing.org> wrote:
>>>
>>>> On Mon, Nov 18, 2019 at 07:21:22PM +0000, Richard Earnshaw (lists)
>> wrote:
>>>>> On 18/11/2019 18:53, Segher Boessenkool wrote:
>>>>>> PR target/92140: clang vs gcc optimizing with adc/sbb
>>>>>> PR fortran/91926: assumed rank optional
>>>>>> PR tree-optimization/91532: [SVE] Redundant predicated store in
>>>> gcc.target/aarch64/fmla_2.c
>>>>>> PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at
>>>> tree-vect-stmts.c:1687
>>>>>> PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction,
>>>> at tree-vect-loop.c:4252
>>>>>> PR c++/92015: internal compiler error: in cxx_eval_array_reference, at
>>>> cp/constexpr.c:2568
>>>>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
>>>> optabs-tree.c:81
>>>>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
>>>> optabs-tree.c:81
>>>>>> PR fortran/92174: runtime error: index 15 out of bounds for type
>>>> 'gfc_expr *[15]
>>>>>>
>>>>>> Most of these aren't helpful at all, and none of these are good commit
>>>>>> summaries.  The PR92173 one actually has identical commit messages
>> btw,
>>>>>> huh.  Ah, the second one (r277288) has the wrong changelog, but in the
>>>>>> actual changelog file as well, not something any tool could fix up (or
>>>>>> have we reached the singularity?)
>>>>>
>>>>> Identical commits are normally from where the same commit is made to
>>>>> multiple branches.  It's not uncommon to see this when bugs are fixed.
>>>>
>>>> This is an actual mistake.  The commits are not identical at all, just
>>>> the commit messages are (and the changelog entries, too).  Not something
>>>> that happens to ften, but of course I hit it in the first random thing I
>>>> pick :-)
>>>>
>>>>> Ultimately the question here is whether something like the above is
>> more
>>>>> or less useful than what we have today, which is summary lines of the
>>>> form:
>>>>>
>>>>> <date> <user> <email>
>>>>
>>>> I already said I would prefer things like
>>>>    Patch related to PR323
>>>> as the patch subject lines.  No one argues that the current state of
>>>> affairs is good.  I argue that replacing this with often wrong and
>>>> irrelevant information isn't the best we can do.
>>>>
>>>
>>> How about using the first line that isn't a ChangeLog date/author line,
>>> without trying to rewrite/augment it?
>>>
>>> Jason
>>>
>>
>> It would certainly be another way of doing it.  Sometimes it would
>> produce almost the same as an unadulterated PR; sometimes it would
>> produce something more meaningful and sometimes it would be pretty
>> useless.  It probably would hit more cases than my current script in
>> that it wouldn't require the commit to mention a PR in it.
>>
>> The main problem is that the first line is often incomplete, and much of
>> it is also wasted with elements like the full path to a file that is
>> quite deep in the tree.  Lets take a quick example (the first I found in
>> the dump I have).
>>
>> 1998-12-17  Vladimir N. Makarov  <vmakarov@cygnus.com>
>>          * config/i60/i960.md (extendqihi2): Fix typo (usage ',' instead of
>>          ';').
>> 1998-12-17  Michael Tiemann  <tiemann@axon.cygnus.com>
>>          * i960.md (extend*, zero_extend*): Don't generate rtl that looks
>>          like (subreg:SI (reg:SI N) 0), because it's wrong, and it hides
>>          optimizations from the combiner.
>>
>> Firstly, this example misses a blank line between the author and the
>> change message itself, which makes distinguishing between this and the
>> multiple authors case harder.  Secondly, the entry really spans two
>> lines and cutting it off at the end of the first line would be, well a
>> bit odd.  We could try to piece things together more, by combining lines
>> until we find a sentence end ( \.$ or \.\s\s ), and we could also strip
>> off more of the path components to just leave the name of the file
>> committed.  For example,
>>
>> i960.md (extendqihi2): Fix typo (usage ',' instead of ';').
>>
>> That might work better, but obviously it's harder to handle and thus
>> more likely to create erroneous summaries.
>>
> 
> Yep. I don't think we need to worry about getting optimal one-line
> summaries for ancient commits; something reasonably unique should be plenty.
> 

Attached is the latest version of my script.  I used (very nearly) this 
to produce a conversion over the weekend and I've uploaded that here:

https://gitlab.com/rearnsha/gcc-trial-20191130

Note, that I might blow this away at any time.  IT IS NOT A FINAL 
CONVERSION.

Some other things to note:
- there are a number of known issues with the version of reposurgeon 
used for this that are being worked on
   - emptycommit-* tags - my control script was out-of-date
   - *deleted* branches - this is being worked on
   - weird dependencies around merges - this is being worked on
   - author attributions are sometimes incorrect - reported

The main difference between the attached script and the one I used for 
this conversion is that ChangeLog change that contain :: inside a 
function list is now handled correctly, resulting in a number of cases 
that were previously being missed now being correctly handled.

Choices I made:
- When a PR is used to derive the summary, I prefix this with 're' (as 
in the Latin 'in re'.
- long change hunks produce poor summaries.  To reduce the overhead:
   - path names are removed, leaving just the final file name
   - multiple files are replaced with [...] after the first filename
   - similarly, multiple function names are replaced with [...]
   - very long comments are truncated, preferably at the strongest
     punctuation mark, but sometimes after key words, such as 'if',
     'when', 'unless' and a few more.  Ultimately, if the line is
     still too long, we just break after an arbitrary space.
- Where possible useful summary lines that appear after an author,
   attribution are hoisted as a summary.
- certain key words in otherwise not very useful summary lines are
   also spotted and used to add [revert] or [backport] annotations to
   the summary.

No changes are made to the main commit log, if we add a new summary 
line, the entire original text is kept.

An example of a summary produced by this is for the commit to r278572, 
where the original log entry is:


     	Backported from mainline
     	2019-08-02  Jakub Jelinek  <jakub@redhat.com>

     	* quadmath.h (M_Eq, M_LOG2Eq, M_LOG10Eq, M_LN2q, M_LN10q, M_PIq,
     	M_PI_2q, M_PI_4q, M_1_PIq, M_2_PIq, M_2_SQRTPIq, M_SQRT2q,
     	M_SQRT1_2q): Use two more decimal places.

And the script then generates:

[backport] quadmath.h (M_Eq, [...]): Use two more decimal places.

as the summary.

R.

[-- Attachment #2: bugdb.py --]
[-- Type: text/x-python, Size: 31670 bytes --]

#!/usr/bin/python2

import requests
import json
import os.path
import codecs
import email.message, email.parser
import re
import signal
import sys

# Files that we read or write.
buglist = "bugids.list"
bugdbfile = "bugs.json"
commits_in = "gcc.commitlog"
commits_out = "gcc.fixedprs"
commits_unfixed = "gcc.unfixed"

bugdb = {}

# Dictionary indexed by bugzilla component.  If the claimed PR component
# matches against the real component, then assume this probably an OK
# matching.  We avoid a lot of false positive warnings this way.
# A special match of "*" means we don't care in this case.  Many bugs
# are filed under, for example, bootstrap or other when in fact the
# real component will ultimately be shown in the commit log.
compalias = {
    "rtl-optimization": ["opt", "optimization", "optimisation", "optimize",
                         "middle-end", "rtl-opt", "rtl_optimization",
                         "rtl-optimizations", "rtl"],
    "tree-optimization": ["opt", "optimization", "optimisation", "optimize",
                          "middle-end", "tree-opt", "tree-optimzation",
                          "graphite", "lto", "tree-optimizations",
                          "tree-optimizer", "ipa", "tree-optimize",
                          "tree-optimizatio"],
    "java": ["gcj", "libgcj", "libjava"],
    "fastjar": ["java"],
    "libgcj": ["java", "libjava"],
    "classpath": ["libgcj", "libjava", "xml", "crypto"],
    "awt": ["classpath", "libjava"],
    "xml": ["classpath", "libjava"],
    "crypto": ["classpath", "libjava"],
    "objc++": ["obj-c++"],
    "c++": ["libstdc++", "diagnostic", "cp"],
    "c": ["diagnostic", "c-family"],
    "libstdc++": ["c++", "libstdc++-v3"],
    "libmudflap": ["mudflap"],
    "preprocessor": ["cpp", "pch"],
    "bootstrap": ["*"],
    "testsuite": ["*"],
    "regression": ["*"],
    "sanitizer": ["sanitize", "ubsan"],
    "other": ["*"],
    "middle-end": ["optimization", "rtl-optimization", "tree-optimization",
                   "tree-opt", "rtl-opt", "ipa", "lto", "middle", "middle-ed"],
    "ipa": ["middle-end", "lto"],
    "lto": ["middle-end", "ipa", "tree-optimization"],
    "target": ["*"],
    "plugins": ["*"],
    "libf2c": ["fortran", "gfortran", "libgfortran", "libfortran"],
    "fortran": ["gfortran", "libgfortran", "libfortran", "forrtran"],
    "libfortran": ["fortran", "gfortran", "libgfortran", "libfofortran"],
    "libgomp": ["fortran"],
    "gcov-profile": ["profile", "gcov"],
    "libffi": ["other"],
    "web": ["documentation"]}

# List of Legacy-IDs where the PR is correct, dispite the anomaly
# checks we perform.
whitelist = ["52862", "53125", "57958", "57959", "58705", "51884", "58535",
             "58542",
             "61329", "61770", "61960", "61984", "63783", "65127", "65128",
             "67653", "68236", "68239",
             "70062", "70542", "70625", "70932", "72072", "72259", "72260",
             "73504", "73940", "73940", "77602", "78312", "78313",
             "80793", "82490", "82518", "83609", "84217", "84295", "84531",
             "84532", "84887", "84895", "86396", "86429", "86458", "86459",
             "86460", "86461", "87066", "87189", "87511", "87512", "87632",
             "88922", "89175", "89921",
             "90004", "91308", "91504", "92158", "92585", "92658", "94054",
             "94226", "94317", "94805", "95382", "95383", "95428", "95673",
             "96396", "96626", "97373", "97375", "97537", "98412", "98926",
             "99480", "99514",
             "100206", "100207", "100209", "100371", "100851", "100961",
             "101264", "101273", "102155", "102348", "102539", "102567",
             "102799", "102920", "103268", "103279", "103308", "104948",
             "104949", "104988", "105052", "105274", "106269", "106582",
             "107816", "108045", "109166", "109167", "109168", "109169",
             "109643", "109644", "109818",
             "110131", "110132", "110627", "110975", "111818", "111947",
             "111952", "112296", "112298", "112611", "112612", "112819",
             "113095", "113119", "113121", "113137", "113627", "113628",
             "113661", "113662",
             "113701", "113702", "113703", "114482", "115200",
             "116613", "116633", "116633", "117824",
             "117852", "118025", "118034", "118142",
             "118742", "118743", "119248", "119485", "119486",
             "120497", "120498", "120499", "120523", "121334", "121338",
             "121949", "122640", "122641", "122700", "122743", "122751",
             "122798", "124362", "125025",
             "125108", "125844", "126675", "127812", "127688", "127689",
             "128272", "128573", "128649", "129871",
             "130016", "131781", "132577", "132587",
             "141646", "142724", "142725", "142833", "144976",
             "152550", "157199", "157784",
             "160456", "160476", "163777",
             "176083", "176167", "176623", "176624",
             "182943", "187842",
             "190100", "193620", "194102", "195610", "199972",
             "201377", "201378", "202642", "202937", "205753", "209250",
             "210999", "211000", "211001", "211002", "214734", "214958",
             "215345", "215386", "215804", "215806", "215807",
             "221207", "221958",
             "233033",
             "242543", "242795",
             "259105",
             "268434",
             "276571", "276987", "276993"
]

# Indexed by Legacy-ID.  Each fixup may contain either the correct PR
# for this commit or an alternative summary string.  If the latter, this
# will form the entire summary for the commit.
fixups = {
    "15985": {"ignore": True},
    "37228": {"summary": "Use memset/memcmp instead of bzero/bcmp."},
    "52264": {"PR": "5373"}, # PR ok, but malformed.
    "57986": {"PR": "7792"},
    "52818": {"PR": "6479"},
    "58876": {"PR": "8481"}, # PR ok, but hard to parse.
    "65177": {"PR": "8808"},
    "65181": {"PR": "8808"},
    "68117": {"PR": "10712"},
    "68118": {"PR": "10712"},
    "71157": {"PR": "11867"},
    "71159": {"PR": "11867"},
    "71856": {"PR": "11415"},
    "75457": {"PR": "12815"},
    "81771": {"PR": "15204"},
    "82028": {"summary": "Multiple fixes: PRs 14692, 15274 and 15463"},
    "84508": {"PR": "16455"},
    "84522": {"PR": "15754"},
    "85966": {"PR": "16935"},
    "86431.1": {"summary": "Revert earlier fix for PR 14029"},
    "86431.2": {"summary": "Revert earlier fix for PR 14029"},
    "98287": {"PR": "17472"},
    "93620": {"PR": "19009"},
    "94658": {"PR": "19736"},
    "94889": {"PR": "19634"},
    "96560": {"PR": "20490"},
    "107451": {"PR": "24236"},
    "110063": {"summary": "PR25024, PR20881, PR23308, PR25538 and PR25710 - Procedure references"},
    "114667": {"PR": "27648"},
    "115858": {"PR": "28452"},
    "122127": {"PR": "30795"},
    "122980": {"PR": "31025"},
    "141612": {"PR": "32519"},
    "146134": {"PR": "38668"},
    "146593": {"PR": "39632"},
    "146650": {"PR": "39632"},
    "151112": {"PR": "28039"},
    "158393": {"PR": "43741"},
    "171924": {"PR": "48401"},
    "174228": {"PR": "46005"},
    "174235": {"PR": "46005"},
    "179230": {"PR": "45012"},
    "188077": {"PR": "52700"},
    "188078": {"PR": "52700"},
    "188079": {"PR": "52700"},
    "206073": {"PR": "35545"},
    "206074": {"PR": "35545"},
    "224527": {"PR": "56766"},
    "268301": {"PR": "89020"},
    "249711": {"summary": "Revert: backport PRs 80382, 80966"},
    "274921": {"summary": "[backport] Enable math functions linking with static library for LTO"},
    "276627": {"PR": "47054"}
    }

full_author = re.compile (r"\s*((Mon|Tue|Wed|Thu|Fri|Sat|Sun)\s+(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)\s+\d{1,2}\s+\d{2}:\d{2}:\d{2}\s+([A-Z]{3}\s+)?\d{4}|\d{4}-\d{2}-\d{2})\s+.+\s[(<][\w.]+@[\w.-]+[>)]")

def read_bugdb(dbfile):
    try:
        with open(dbfile, "r") as f:
            bugdb.update(json.load(f))
            print(len(bugdb))
            f.close()
    except:
        return

def write_bugdb(dbfile):
    try:
        os.delete(dbfile + ".bak")
    except:
        pass
    try:
        os.rename(dbfile, dbfile + ".bak")
    except:
        pass
    try:
        with open(dbfile, "w") as f:
            json.dump(bugdb, f)
            f.close()
    except:
        print("Failed to write" + dbfile)
        exit()

def fetch_sublist(sublist):
    url = 'https://gcc.gnu.org/bugzilla/rest.cgi/bug?id='
    url += ','.join([elem for elem in sublist])
    url += '&include_fields=id,summary,component,resolution'

    resp = requests.get(url)

    if resp.status_code != 200:
        print(resp.status_code)
    return resp.json()

def process(jdata):
    buglist = jdata['bugs']
    for bug in buglist:
        bugdb[str(bug['id'])] = {"summary": bug['summary'],
                                 "component": bug['component'],
                                 "resolution": bug['resolution']}

    print(len(bugdb))

def fetchall(bugids):
    f = open(bugids, "r")
    allbugids = f.read().splitlines()
    sublist = []
    for bugid in allbugids:
        if str(bugid) not in bugdb:
            #print("missing: " + id)
            sublist.append(bugid)
            if len(sublist) == 200:
                process(fetch_sublist(sublist))
                sublist = []
    for fixup in fixups.values():
        if "PR" in fixup and fixup['PR'] not in bugdb:
            sublist.append(fixup['PR'])
            if len(sublist) == 200:
                process(fetch_sublist(sublist))
                sublist = []
    if sublist:
        process(fetch_sublist(sublist))

# This is lifted from the python version of reposurgeon, since we are
# parsing objects it created.

# Since we assume python2
rspolicy = None

class RepoSurgeonEmail(email.message.Message, object):
    "Specialized email message with a distinguishing starter."
    Divider = 78 * "-"
    __hash__ = None
    def __init__(self, **kwargs):
        if rspolicy:
            # This activates the Python 3 email header handling hack
            kwargs['policy'] = rspolicy
        email.message.Message.__init__(self, **kwargs)
        self.set_unixfrom(RepoSurgeonEmail.Divider)
    @staticmethod
    def readmsg(fp):
        msg = ''
        firstline = fp.readline()
        if not firstline:
            return None
        elif not firstline.startswith(RepoSurgeonEmail.Divider):
            msg = firstline
        while True:
            line = fp.readline()
            if not line:
                break
            # Not impossible for this to get spoofed, but *highly* unlikely
            if line == "\n." + RepoSurgeonEmail.Divider + "\n":
                line = "\n" + RepoSurgeonEmail.Divider + "\n"
            if line.startswith(RepoSurgeonEmail.Divider):
                break
            msg += line
        return msg
    def payload(self):
        "Return message body - works because not multipart."
        return self.get_payload()
    def __str__(self):
        out = super(RepoSurgeonEmail, self).as_string(unixfrom=True)
        out = out.replace("\n" + RepoSurgeonEmail.Divider + "\n",
                          "\n." + RepoSurgeonEmail.Divider + "\n")
        out = out.replace("\n>From", "\nFrom")
        return out

# Close states that suggest that the bug is unlikely to be a correct
# target of a fix.
badclose = ["INVALID"]
# Would be nice to add ["WORKSFORME", "WONTFIX"], but too many false
# positives on early PRs.

# Fuzzy match a claimed bugcat against the component in the PR.  This avoids
# a number of likely false negatives without over relaxing the desire to
# detect possibly inaccurate PR numbers.
def component_mismatch(bugcat, bugid):
    # We're not bothered about case
    bugcat = bugcat.lower()
    component = bugdb[bugid]['component']
    # It's extremely unlikely that any bug classified as spam should match
    # a PR.  It's also pretty unlikely that a bug closed as INVALID would
    # do so either.  So flag up both cases.
    if (component == "spam" or bugdb[bugid]['resolution'] in badclose):
        return True
    # These blanket components lead to far too many false positives, so
    # just ignore them.  This is essentially the reverse map of the "*"
    # match later on.
    if (bugcat in ["boostrap", "bootstrap", "target", "plugins", "testsuite",
                   "other", "ice", "gcc", "translation", "regression", "build",
                   "diagnostic", "wrong-code"] or
        # These are nonesense categories, since they refer to
        # components outside of GCC.
        bugcat in ["binutils", "gas", "ld"] or
        bugcat == component):
        return False
    if component not in compalias:
        return True
    if ("*" in compalias[component] or
        bugcat in compalias[component]):
        return False
    return True

def summary_from_pr(msg, payload, lines):
    # Deal first with a first line that is a PR and a summary of its own,
    # we don't want to replace that.
    if (re.match(r"^\s*PR(\s+([^/\s]+)/|\s*#?)\d+\b", lines[0])
        and not re.match(r"^\s*PR(\s+([^/\s]+)/|\s*#?)\d+\s*[-:.]?\s*$",
                         lines[0])):
        return None

    y = re.search(r"(^|\s+|[/\(\[])PR(\s+([^/\s]+)/|\s*#?)(\d+)\b",
                  payload)
    if not y:
        return None
    bugcat = y.group(3)
    bugid = y.group(4)
    if bugid not in bugdb:
        #print("PR " + bugid + " not found in database")
        return None
    summary = bugdb[bugid]['summary'].encode("utf-8")
    # Early on there were multiple GNATS databases for bugs;
    # later they were merged into a single database, but the
    # PR numbers were changed.  Don't trust bugs below 1000
    # unless the component matches the one mentioned in the
    # log (if it even has one).
    if (int(bugid) < 1000 and
        (bugcat == None or bugcat != bugdb[bugid]['component'])):
        print("E" + msg['Event-Number'] + "(r" + msg['Legacy-ID']
              + "): Ignoring PR " + bugid
              + " - no component or component mismatch")
        return None
    elif (bugcat != None and msg['Legacy-ID'] not in whitelist
          and component_mismatch(bugcat, bugid)):
        problem = ("E" + msg['Event-Number'] + "(r" + msg['Legacy-ID']
                   + "): '" + bugcat + "/" + bugid + "'")
        if (bugdb[bugid]['resolution'] in badclose):
            problem += (" closed as "
                        + bugdb[bugid]['resolution'].encode("utf-8"))
            summary += (" [checkme: "
                        + bugdb[bugid]['resolution'].encode("utf-8")
                        + " SVN r" + msg['Legacy-ID'] + "]")
        else:
            problem += (" mismatch PR "
                        + bugdb[bugid]['component'].encode("utf-8"))
            summary += (" [checkme: " + bugcat + " SVN r"
                        + msg['Legacy-ID'] + "]")
        print(problem)

    z = re.match(r"\s*\[[^\]]*[Rr]egression\s*\]\s*:?\s*(.*)", summary)
    if z:
        #print(summary)
        summary = z.group(1)
    summary = ("re PR " + bugdb[bugid]['component'].encode("utf-8")
               + "/" + bugid + " (" + summary + ")")
    return summary

# Similar to strip_unintersting line, but used when we have a single
# line that looks potentially interesting (because it begins with
# a letter and ends with a period and we want to decide whether we really
# want it as the final summary.
def interesting_line(line):
    if re.match(r"^\s*([Ff]ix(e[ds])? (for )?)?PR(\s+[^/\s]+/|\s*#?)(\d+)[\.:]?\s*$",
                line):
        return False
    if re.match(r"\s*([Ff]ix|[Pp]atch) from", line):
        return False
    if re.match(r"\s*([Mm]erged?|[Bb]ack[-\s]?port(ed|s)?) (\w+ )?from ",
                line):
        return False
    if re.match(r"\s*[Ss]ynchronize with", line):
        return False
    if re.match(r"\s*[Ff]rom ", line):
        return False
    if re.match(r"\s*[Ii]n\s\S+$", line):
        return False
    if re.match(r"\s*(Reviewed|Signed-off|Acked|Reported)-by:", line):
        return False
    if re.match(r"\s*Reviewed-on:", line):
        return False
    return True

def strip_uninteresting_lines(lines):
    backport = False
    revert = False
    keepgoing = True
    # Strip any blank lines, or any line containing a single word, unless
    # that word is revert.  Mostly these make uninteresting summaries.
    # Also strip lines that begin "* From ...:", this was an early way
    # of attributing a contributor who did not make a commit themselves.
    while lines:
        if re.match(r"^\s*$", lines[0]):
            pass
        elif full_author.match(lines[0]):
            # Strip any author lines
            while (len(lines) > 1
                   and re.match(r"\s+\w.*\s<[\w.]+@[\w.-]+>", lines[1])):
                lines = lines[1:]
        elif re.match(r"\s*PR\d+", lines[0]):
            keepgoing = False
        elif re.match(r"\s*\*\s*From\s.*:$", lines[0]):
            pass
        elif re.match(r"\W*([Rr]evert(ed)?|[Bb]ack[-\s]*out)(\.|.*:)?$",
                      lines[0]):
            revert = True
        elif re.match(r"\W*([Bb]ack[-\s]*port(|s|ed)|[Mm]erged?)\b",
                      lines[0]):
            backport = True
        elif re.match(r"\s*(\S+\s*|)$", lines[0]):
            pass
        else:
            keepgoing = False
        if not keepgoing:
            break
        lines = lines[1:]

    return lines, backport, revert

changemax = 80
def find_best_breakpoint(change):
    # Try, in turn, looking for ':', ';', ',' and ' - '.  The idea is
    # to find the strongest natural break within the message.
    # Avoid breaking at '):' This is more likely to be a change hunk that
    # was malformed in some way and produces poor breaks.  Similarly for
    # :: which is often a OO function separator
    x = re.match(r"^(.*?[^\)\]:]:)\s", change)
    if not x:
        x = re.match(r"^(.*?;)\s", change)
    if not x:
        x = re.match(r"^(.*?,)\s", change)
    if not x:
        x = re.match(r"^(.*?\s-(\s|$))\s", change)
    if x:
        return x.group(1)[0:len(x.group(1)) - 1]

    # Consider words that create subclauses, breaks after these are more
    # natural, but not if they are too early in the line.
    x = re.match(r"^(.*?\b(if|when|unless))(\s|$)",
                 change[changemax / 2:changemax])
    if x:
        return change[:(changemax / 2)] + x.group(1)

    x = re.match(r"^(.*\s)", change[:changemax])
    if x:
        return x.group(1)[0:len(x.group(1)) - 1]

    return change[:changemax]

badlines=[r"\s*$",
          r"\s*\*(\s|.*:(\s|$))",
          r"\s*\((\S+,\s+)*\S+\):",
          r"\s*/?(gcc|ada|testsuite|boehm-gc)(/[-\+\w])*/?:?$",
          r"\s*/?(brig|c|[cC]\+\+(filt)?|cfamily|ch)(/[-\+\w])*/?:?$",
          r"\s*/?(config|contrib|cp|doc|f|F77|fastjar)(/[-\+\w])*/?:?$",
          r"\s*/?([Ff]ortran|gcp|gfortran|gnattools)(/[-\+\w])*/?:?$",
          r"\s*/?(go|gotools|include|intl|java)(/[-\+\w])*/?:?$",
          r"\s*/?lib(ada|asan|atomic|backtrace|banshee)(/[-\+\w])*/?:?$",
          r"\s*/?lib(cc1|cpp|ffi|f2c|gcc|fortran|go|gomp)(/[-\+\w])*/?:?$",
          r"\s*/?lib(hsail-rt|iberty|io|itm|java|mudflap)(/[-\+\w])*/?:?$",
          r"\s*/?lib(objc|offloadmic|phobos|quadmath)(/[-\+\w])*/?:?$",
          r"\s*/?lib(sanitizer|ssp|stdc\+\+|vtv)(/[-\+\w])*/?:?$",
          r"\s*/?(lto|lto-plugin|maintainer-scripts|objc)(/[-\+\w])*/?:?$",
          r"\s*/?(src|zlib)(/[-\+\w])*/?:?$",
          r"\s\[gcc[^\]]*\]$",
          r"\(top level\)$"]

# Return the first sentence, and any remaining text.
def find_first_sentence(lines):
    # Never merge a PR number with additional lines
    if re.match(r"\s*PR(\s+[^/\s]+/|\s*#?)(\d+)", lines[0]):
        return lines[0], lines[1:]
    sentence = lines[0]
    x = re.match(r"\s*(.*?[\.\?!])(\s+(.*)|$)", sentence)
    if x:
        if x.group(3):
            return x.group(1), [x.group(3)] + lines[1:]
        return x.group(1), lines[1:]
    lines = lines[1:]
    while lines:
        for badline in badlines:
            if re.match(badline, lines[0]):
                return sentence, lines
        x = re.match(r"\s*(.*?\.)(\s+(.*)|$)", lines[0])
        if x:
            if x.group(3):
                return sentence + " " + x.group(1), [x.group(3)] + lines[1:]
            return sentence + " " + x.group(1), lines[1:]
        sentence += " " + re.match(r"\s*(\S.*)$", lines[0]).group(1)
        lines = lines[1:]
    return sentence, lines

def trim_excess_ws(mystr):
    # Strip any leading white space.
    mystr = re.sub(r"^\s+", "", mystr)
    # Canonicalize all white space into single space characters
    mystr = re.sub(r"\s{2,}", " ", mystr)
    # And any trailing white space
    mystr = re.sub(r"\s+$", "", mystr)
    return mystr

def simplify_funclist(funcstr):
    funcstr = trim_excess_ws(funcstr)
    # Sanity check
    if funcstr[0] != "(" or funcstr[-1] != ")":
        return funcstr
    funcstr = funcstr[1:-1]
    firstfunc = re.match(r"^([^\(]+?(\([^\)]*\))?),\s(.*)", funcstr)
    if firstfunc and len(firstfunc.group(3)) > 10:
        return " (" + firstfunc.group(1) + ", [...])"
    return " (" + funcstr + ")"

def simplify_filelist(filestr):
    filestr = trim_excess_ws(filestr)
    x = re.match(r"(\S+/)?(.+?)((,)?\s+(.*)|$)", filestr)
    if not x:
        return filestr
    sep = ", " if x.group(4) else " "
    if not x.group(5):
        return x.group(2)
    y = re.match(r"(\S+/)?(.+?)(,?\s+(.*)|$)", x.group(5))
    # If the first two 'files' do not contain a '.', then we might not have
    # a real file list.  Better to just return the original string.
    if sep == " " and not (re.match(r"\S+\.\S", x.group(2))
                           or re.match(r"\S+\.\S", y.group(2))):
        return filestr
    if y.group(4) or len(y.group(2)) > 10:
        return x.group(2) + sep + "[...]"
    return x.group(2) + sep + y.group(2)

def summary_from_change(msg, sentence):
    # Pattern to match a commit change entry in GNU ChangeLog style.  There
    # are some variants of this, but they are rare enough that we don't
    # worry too much about not handling them.
    # This RE is just too long to comprehend when written as a single
    # string...
    re_files = r"([-=\.\w\d_/\*\?\+,\s\[\]\{\}\$]+)" # 1 group
    re_funcs = r"(\s*\(.*?\))?"           # 1 group
    re_cases = r"\s*(\[[^\]]+\])?"        # 1 group (unused)
    re_case2 = r"(<[^>]+>)?"              # 1 group (unused)
    re_descr = r"\s*:(\s+(.*))?$"         # 2 groups
    x = re.match(r"\s*\*\s*" + re_files + re_funcs + re_cases + re_case2
                 + re_descr,
                 sentence)
    if not x:
        # A relatively common typing error is to leave out the closing
        # ')' from a function list.  Try again for that option.  We
        # use a simpler match pattern for this case, leaving out the
        # cases variants.
        x = re.match(r"\s*\*\s*" + re_files + r"(\s*\([^\)]*?)" + re_descr,
                     sentence)
        if not x:
            print ("Failed to parse: " + sentence)
            return None
        filename = simplify_filelist(x.group(1))
        funcs = simplify_funclist(x.group(2) + ")")
        change = x.group(4)
    else:
        filename = simplify_filelist(x.group(1))
        funcs = simplify_funclist(x.group(2)) if x.group(2) else ""
        change = x.group(6) if x.group(6) else ""
    # Just use the basename for any filename.

    if len(change) < changemax + 5:
        return trim_excess_ws(filename + funcs + ": " + change)
    while (len(change) > changemax):
        change = find_best_breakpoint(change)
    change += "..."
    return trim_excess_ws(filename + funcs + ": " + change)

def find_best_summary(msg, lines):
    sentence, _ = find_first_sentence(lines)
    # ChangeLog entries look like "* file[ (func-list)]: change.
    if re.match(r"\s*\*\s*.+:\s", sentence):
        return summary_from_change(msg, sentence)

    return None

def already_good_summary(lines):
    while lines and lines[0] == "":
        lines = lines[1:]
    # No non-blank lines.  Nothing we can do to make this good, so best
    # to stop now.
    if not lines:
        return True
    # Anything created by cvs2svn should be left alone
    if re.search(r"by cvs2svn", lines[0]):
        return True
    # Single word lines, committer tags or simple PR tags don't make a
    # good summary
    if (full_author.match(lines[0])
        or re.match(r"\s*PR(\s+[^/\s]+/|\s*#?)(\d+)\s*$", lines[0])
        or re.match(r"s*\S+\s*$", lines[0])):
        return False
    # We likely can't make a single-line commit message better.
    if len(lines) == 1:
        return True
    if re.match(r"\s*\*", lines[0]):
        return False
    # A 'real' sentence, ie more than one word and ending with a
    # punctuation mark.  We don't need a blank line in this case as
    # reposurgeon's gitify will handle this for us.
    if re.match(r"\s*[-\w\[\(\{\]\)\}_,.:\']\S*\s+\S.*[.:;,?!]$", lines[0]):
        return interesting_line(lines[0])
    if not interesting_line(lines[0]):
        return False
    # If the second line is blank, treat this as good.
    if re.match(r"\s*$", lines[1]):
        return True
    # It might be a single-line summary that is wrapped onto more than
    # one line.  Handle this case as it's unlikely we can improve it.
    # If the line looks overly long, then we may want to produce a shorter
    # version, so punt.
    sentence, remnant = find_first_sentence(lines)
    if (len(sentence) < 120
        and remnant
        and re.match(r"\s*$", remnant[0])):
        return True
    return False

def summary_from_sentence(sentence, remnant):
    # Ignore anything that looks like a change hunk.
    if re.match(r"\s*\*", sentence):
        return None
    if not interesting_line(sentence):
        return None
    sentence = trim_excess_ws(sentence)
    length = len(sentence)
    if length < 120 and not remnant:
        return None
    elif length < 120:
        return sentence

    return find_best_breakpoint(sentence) + "..."

def processmsg(msg):
    payload = msg.get_payload()
    summary = None

    # Ignore events tagged with "emptycommit-*", these will be deleted
    # later on.
    if 'Tag-Name' in msg and re.match(r"^emptycommit-", msg['Tag-Name']):
        return None
    # Look to see if this event has a specific fixup.  Use it if so.
    if msg['Legacy-ID'] in fixups:
        fixup = fixups[msg['Legacy-ID']]
        if 'ignore' in fixup:
            return None
        if "PR" in fixup:
            summary = bugdb[fixup['PR']]['summary'].encode("utf-8")
            z = re.match(r"\s*\[[^\]]*[Rr]egression\s*\]\s*:?\s*(.*)", summary)
            if z:
                summary = z.group(1)
            summary = ("re PR "
                       + bugdb[fixup['PR']]['component'].encode("utf-8")
                       + "/" + fixup['PR'] + " (" + summary + ")")
        elif "summary" in fixup:
            summary = fixup['summary']
        else:
            print("Invalid fixup for Legacy-ID " + msg['Legacy-ID'])
            exit()

    lines = payload.splitlines()
    # Don't mess with something that looks like a good summary.
    if not summary and already_good_summary(lines):
        return None

    while lines and re.match(r"\s*$", lines[-1]):
        lines = lines[:-1]

    # Look to see if this event is a backport of multiple PRs.  Just
    # set the summary to a quick list if so.
    if not summary:
        allprs = re.findall(r"\b\s*PR(\s+([^/\s]+)/|\s*#?)(\d+)\b", payload)
        allprnos = list(dict.fromkeys([int(pr[2]) for pr in allprs]))
        allprnos.sort()
        if ((len(allprnos) > 3 and
             re.search(r"\b[Bb]ack[- ]?port(s|ed)?\b", payload))
            or (len(allprnos) > 1 and
                re.search(r"\b[Bb]ack[- ]?ports", payload))):
            prs = allprnos if len(allprnos) < 10 else allprnos[:10]
            #print prs[0]
            summary = "Backport PRs " + str(prs[0])
            for pr in prs[1:]:
                summary += ", " + str(pr)
            if len(allprnos) > 10:
                summary += " and more"

    backport = False
    revert = False
    if not summary:
        while lines and lines[0] == "":
            lines = lines[1:]
        if not lines:
            return None
        multicommit = False
        x = full_author.match(lines[0])
        author_line = lines[0]
        if x:
            if len(lines) > 2:
                is_backport = re.search(r"\b[Bb]ack[- ]?port", payload)
                for line in lines[2:]:
                    if full_author.match(line):
                        # If this looks like a backport, allow one
                        # mismatch, since often we have the author of
                        # the original commit and the author of the
                        # backport its rare to get a full match in
                        # that case.
                        if is_backport and author_line != line:
                            is_backport = None
                            author_line = line
                        elif author_line != line and lines[0] != line:
                            multicommit = True
                            break
        if multicommit:
            summary = "[multiple changes]"
            bugid = ""
            if author_line != lines[0]:
                backport = True

    if not summary:
        lines, backport, revert = strip_uninteresting_lines(lines)
        if not lines:
            return None
        sentence, remnant = find_first_sentence(lines)
        summary = summary_from_sentence(sentence, remnant)

    if not summary:
        summary = summary_from_pr(msg, payload, lines)

    if not summary:
        summary = find_best_summary(msg, lines)

    if not summary:
        return None

    preamble = ""
    if revert:
        preamble = "[revert]"
    if backport:
        preamble += "[backport]"
    if preamble != "":
        if summary[0] == "[":
            summary = preamble + summary
        else:
            summary = preamble + " " + summary

    newmsg = RepoSurgeonEmail()

    # All messages should have an event number, so this will hopefully
    # raise an exception if it fails
    newmsg['Event-Number'] = msg['Event-Number']
    if "Check-Text" in msg:
        newmsg['Check-Text'] = msg['Check-Text']
    # We must copy the tag name if it exists.
    if "Tag-Name" in msg:
        newmsg['Tag-Name'] = msg['Tag-Name']
    try:
        newmsg.set_payload(summary + "\n\n" + payload)
        return str(newmsg)
    except:
        print("Unicode??? Cannot format message for Event "
              + msg['Event-Number'] +
              (summary if bugid == "" else (" PR " + bugid)))
        return None

def main():
    scrape_bugzilla = True
    for arg in sys.argv[1:]:
        if arg == "--noscrape":
            scrape_bugzilla = False
        else:
            print "Unknown option: " + arg
            exit(1)

    read_bugdb(bugdbfile)
    if scrape_bugzilla:
        try:
            fetchall(buglist)
        except KeyboardInterrupt:
            write_bugdb(bugdbfile)
            exit()

        write_bugdb(bugdbfile)

    commitlog = open(commits_in, "r")
    newlog = open(commits_out, "w")
    unfixed = open(commits_unfixed, "w")

    while True:
        msg = RepoSurgeonEmail.readmsg(commitlog)
        if not msg:
            break
        newmsg = processmsg(email.message_from_string(msg))
        if newmsg:
            newlog.write(newmsg)
        else:
            unfixed.write(msg)

    newlog.close()
    commitlog.close()
    unfixed.close()

if __name__ == '__main__':
    main()

Re: Commit messages and the move to git

[Segher Boessenkool]

Hi,

On Mon, Dec 02, 2019 at 10:54:17AM +0000, Richard Earnshaw (lists) wrote:
>   - author attributions are sometimes incorrect - reported

This would disqualify that "conversion", for me at least.  Keeping all
warts we had in SVN is better than adding new lies, lies about important
matters even.

> - certain key words in otherwise not very useful summary lines are
>   also spotted and used to add [revert] or [backport] annotations to
>   the summary.

You won't see tags like that from anyone who uses the normal git commit
flows: the piece of the mail subject between [] is deleted.

> No changes are made to the main commit log, if we add a new summary 
> line, the entire original text is kept.

That is good (an important requirement even).


Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 02/12/2019 15:35, Segher Boessenkool wrote:
> Hi,
> 
> On Mon, Dec 02, 2019 at 10:54:17AM +0000, Richard Earnshaw (lists) wrote:
>>   - author attributions are sometimes incorrect - reported
> 
> This would disqualify that "conversion", for me at least.  Keeping all
> warts we had in SVN is better than adding new lies, lies about important
> matters even.
Indeed, but it's easy to turn off the option that tries to do this, if
it can't be made to work correctly.  We'd then be back with the existing
'author == committer' situation.

> 
>> - certain key words in otherwise not very useful summary lines are
>>   also spotted and used to add [revert] or [backport] annotations to
>>   the summary.
> 
> You won't see tags like that from anyone who uses the normal git commit
> flows: the piece of the mail subject between [] is deleted.

Well, true if you use "git am" without the -k or -b options; false
otherwise.  We have plenty of existing patches in the repo that have
tags like this, though it doesn't appear to be the 'git way' I grant you.

We could extend the script to rewrite all [tag] attributions in tag:
form, but I'm not really sure it's worth it.

> 
>> No changes are made to the main commit log, if we add a new summary 
>> line, the entire original text is kept.
> 
> That is good (an important requirement even).
> 

Yes, I even steer clear of trimming blank lines at the head or tail of
the message, but it's possible that reposurgeon might do that itself later.

> 
> Segher
> 

The real question at this point is whether or not these commit summaries
are better than the existing ones.  Personally, I think they are (or I
wouldn't have spent the time working on this), but I'm not the only
person with an interest here...
R

Re: Commit messages and the move to git

[Segher Boessenkool]

On Mon, Dec 02, 2019 at 04:18:59PM +0000, Richard Earnshaw (lists) wrote:
> On 02/12/2019 15:35, Segher Boessenkool wrote:
> > On Mon, Dec 02, 2019 at 10:54:17AM +0000, Richard Earnshaw (lists) wrote:
> >>   - author attributions are sometimes incorrect - reported
> > 
> > This would disqualify that "conversion", for me at least.  Keeping all
> > warts we had in SVN is better than adding new lies, lies about important
> > matters even.
> Indeed, but it's easy to turn off the option that tries to do this, if
> it can't be made to work correctly.  We'd then be back with the existing
> 'author == committer' situation.

But we need to be *sure* this is done correctly.  The only safe thing
to do is to turn off all such options, if we cannot trust them.

> >> - certain key words in otherwise not very useful summary lines are
> >>   also spotted and used to add [revert] or [backport] annotations to
> >>   the summary.
> > 
> > You won't see tags like that from anyone who uses the normal git commit
> > flows: the piece of the mail subject between [] is deleted.
> 
> Well, true if you use "git am" without the -k or -b options; false
> otherwise.  We have plenty of existing patches in the repo that have
> tags like this, though it doesn't appear to be the 'git way' I grant you.

Yes, "the normal commit flows" :-)

> We could extend the script to rewrite all [tag] attributions in tag:
> form, but I'm not really sure it's worth it.

Sure; I'm just saying rewriting old commit messages in such a style that
they keep standing out from new ones is a bit of a weird choice.

> >> No changes are made to the main commit log, if we add a new summary 
> >> line, the entire original text is kept.
> > 
> > That is good (an important requirement even).
> 
> Yes, I even steer clear of trimming blank lines at the head or tail of
> the message, but it's possible that reposurgeon might do that itself later.

> The real question at this point is whether or not these commit summaries
> are better than the existing ones.  Personally, I think they are (or I
> wouldn't have spent the time working on this), but I'm not the only
> person with an interest here...

Thanks for the effort, regardless of the outcome!


Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 02/12/2019 17:25, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 04:18:59PM +0000, Richard Earnshaw (lists) wrote:
>> On 02/12/2019 15:35, Segher Boessenkool wrote:
>>> On Mon, Dec 02, 2019 at 10:54:17AM +0000, Richard Earnshaw (lists) wrote:
>>>>   - author attributions are sometimes incorrect - reported
>>>
>>> This would disqualify that "conversion", for me at least.  Keeping all
>>> warts we had in SVN is better than adding new lies, lies about important
>>> matters even.
>> Indeed, but it's easy to turn off the option that tries to do this, if
>> it can't be made to work correctly.  We'd then be back with the existing
>> 'author == committer' situation.
> 
> But we need to be *sure* this is done correctly.  The only safe thing
> to do is to turn off all such options, if we cannot trust them.

Of course.  But that's a decision that can be made quite late, because
we know we *can* turn them off if we want to.

> 
>>>> - certain key words in otherwise not very useful summary lines are
>>>>   also spotted and used to add [revert] or [backport] annotations to
>>>>   the summary.
>>>
>>> You won't see tags like that from anyone who uses the normal git commit
>>> flows: the piece of the mail subject between [] is deleted.
>>
>> Well, true if you use "git am" without the -k or -b options; false
>> otherwise.  We have plenty of existing patches in the repo that have
>> tags like this, though it doesn't appear to be the 'git way' I grant you.
> 
> Yes, "the normal commit flows" :-)
> 

Well my normal commit flow these days is to use -b, because that only
removes "[PATCH...]" annotations.

Nevertheless, we will most likely keep any existing "[...]" tags.

>> We could extend the script to rewrite all [tag] attributions in tag:
>> form, but I'm not really sure it's worth it.
> 
> Sure; I'm just saying rewriting old commit messages in such a style that
> they keep standing out from new ones is a bit of a weird choice.
> 

One of the advantages of doing this in a script is that we have exactly
three places in the script to change, and that's a trivial operation to
do.  Tweaking the logic overall is much harder as it can have surprising
effects at times.

>>>> No changes are made to the main commit log, if we add a new summary 
>>>> line, the entire original text is kept.
>>>
>>> That is good (an important requirement even).
>>
>> Yes, I even steer clear of trimming blank lines at the head or tail of
>> the message, but it's possible that reposurgeon might do that itself later.
> 
>> The real question at this point is whether or not these commit summaries
>> are better than the existing ones.  Personally, I think they are (or I
>> wouldn't have spent the time working on this), but I'm not the only
>> person with an interest here...
> 
> Thanks for the effort, regardless of the outcome!
> 
> 
> Segher
> 

R.

Re: Commit messages and the move to git

[Segher Boessenkool]

On Mon, Dec 02, 2019 at 05:47:08PM +0000, Richard Earnshaw (lists) wrote:
> On 02/12/2019 17:25, Segher Boessenkool wrote:
> > On Mon, Dec 02, 2019 at 04:18:59PM +0000, Richard Earnshaw (lists) wrote:
> >> On 02/12/2019 15:35, Segher Boessenkool wrote:
> >>> On Mon, Dec 02, 2019 at 10:54:17AM +0000, Richard Earnshaw (lists) wrote:
> >>>>   - author attributions are sometimes incorrect - reported
> >>>
> >>> This would disqualify that "conversion", for me at least.  Keeping all
> >>> warts we had in SVN is better than adding new lies, lies about important
> >>> matters even.
> >> Indeed, but it's easy to turn off the option that tries to do this, if
> >> it can't be made to work correctly.  We'd then be back with the existing
> >> 'author == committer' situation.
> > 
> > But we need to be *sure* this is done correctly.  The only safe thing
> > to do is to turn off all such options, if we cannot trust them.
> 
> Of course.  But that's a decision that can be made quite late, because
> we know we *can* turn them off if we want to.

Do we postpone the transition another few months because we have to check
all commits for mistakes the conversion tool made because it tried to be
"smart"?

Or will we rush in these changes, unnecessary errors and all, because
people have invested time in doing this?

It is not a decision that can be made late.  It is a *design decision*.


Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 02/12/2019 18:00, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 05:47:08PM +0000, Richard Earnshaw (lists) wrote:
>> On 02/12/2019 17:25, Segher Boessenkool wrote:
>>> On Mon, Dec 02, 2019 at 04:18:59PM +0000, Richard Earnshaw (lists) wrote:
>>>> On 02/12/2019 15:35, Segher Boessenkool wrote:
>>>>> On Mon, Dec 02, 2019 at 10:54:17AM +0000, Richard Earnshaw (lists) wrote:
>>>>>>   - author attributions are sometimes incorrect - reported
>>>>>
>>>>> This would disqualify that "conversion", for me at least.  Keeping all
>>>>> warts we had in SVN is better than adding new lies, lies about important
>>>>> matters even.
>>>> Indeed, but it's easy to turn off the option that tries to do this, if
>>>> it can't be made to work correctly.  We'd then be back with the existing
>>>> 'author == committer' situation.
>>>
>>> But we need to be *sure* this is done correctly.  The only safe thing
>>> to do is to turn off all such options, if we cannot trust them.
>>
>> Of course.  But that's a decision that can be made quite late, because
>> we know we *can* turn them off if we want to.
> 
> Do we postpone the transition another few months because we have to check
> all commits for mistakes the conversion tool made because it tried to be
> "smart"?
> 
> Or will we rush in these changes, unnecessary errors and all, because
> people have invested time in doing this?
> 
> It is not a decision that can be made late.  It is a *design decision*.
> 
> 

It's a one-line edit to the lift script.  So it's a conversion *choice*.

R.

Re: Commit messages and the move to git

[Eric S. Raymond]

Segher Boessenkool <segher@kernel.crashing.org>:
> Do we postpone the transition another few months because we have to check
> all commits for mistakes the conversion tool made because it tried to be
> "smart"?
> 
> Or will we rush in these changes, unnecessary errors and all, because
> people have invested time in doing this?
> 
> It is not a decision that can be made late.  It is a *design decision*.

Besr in mind that the tool is continuing to improve.  There are now three
people working on it effectively full-time in response to this conversion.

We will fix the attribution bug. Compared to dealing with dumpfile
malformations that sort of thing is a pretty easy problem once we have
a way to reproduce it.

At this point my only serious worry is what kinds of contortions we'll 
need to go through to get around the effects of the GCC/EGCS merge.
I'll be concentrating on that once I finish debugging the analyzer
rewrite.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Richard Sandiford]

"Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com> writes:
> The real question at this point is whether or not these commit summaries
> are better than the existing ones.  Personally, I think they are (or I
> wouldn't have spent the time working on this), but I'm not the only
> person with an interest here...

+1 for having this (not that it's a vote).  Of the two extremes,
the git-svn squashed-clog summaries aren't readable and something
ultra-conservative like "SVN commit rNNNNN" wouldn't be useful in
--oneline output.  The scripted summaries seem like a nice compromise
between the two.  I don't think it matters if the script happens to
generate a few misleading summaries here and there, given that it
preserves the original message as well.

Thanks,
Richard

Re: Commit messages and the move to git

[Joseph Myers]

On Mon, 2 Dec 2019, Segher Boessenkool wrote:

> Sure; I'm just saying rewriting old commit messages in such a style that
> they keep standing out from new ones is a bit of a weird choice.

I'd say the rewrites make them stand out *less* (if people avoid having 
new commit messages whose summary line is just the ChangeLog header line).

Simply having the Legacy-ID in the commit message will be a visible 
difference from new commit messages.  But I'm happy it's desirable to have 
it there, because references to SVN revisions in list archives are so 
common and having it in the commit messages makes it very quick and easy 
to map to a git commit id, without needing any on-the-side lists of commit 
mappings or other tools.  (While reviewing conversions to find and fix 
issues, it's *extremely* useful to have it there to help find 
corresponding commits to compare commit contents, parents, authors and 
other data between SVN and git.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Segher Boessenkool]

On Mon, Dec 02, 2019 at 08:24:47PM +0000, Joseph Myers wrote:
> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
> 
> > Sure; I'm just saying rewriting old commit messages in such a style that
> > they keep standing out from new ones is a bit of a weird choice.
> 
> I'd say the rewrites make them stand out *less* (if people avoid having 
> new commit messages whose summary line is just the ChangeLog header line).

New commits will not start with [smth] in general.  Of course you *can*
do that, with enough effort.  You can also have two consecutive empty
lines in your commit messages just fine, but git won't let you without
a fight.  This is similar.

> Simply having the Legacy-ID in the commit message will be a visible 
> difference from new commit messages.  But I'm happy it's desirable to have 
> it there, because references to SVN revisions in list archives are so 
> common and having it in the commit messages makes it very quick and easy 
> to map to a git commit id, without needing any on-the-side lists of commit 
> mappings or other tools.

Yes.  Either in the subject line, or later in the commit message (as
with git-svn).  We can quibble about where is best, but (hopefully)
everyone agrees we need the SVN id *somewhere* :-)


Segher

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 03/12/2019 00:47, Segher Boessenkool wrote:
> On Mon, Dec 02, 2019 at 08:24:47PM +0000, Joseph Myers wrote:
>> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
>>
>>> Sure; I'm just saying rewriting old commit messages in such a style that
>>> they keep standing out from new ones is a bit of a weird choice.
>>
>> I'd say the rewrites make them stand out *less* (if people avoid having
>> new commit messages whose summary line is just the ChangeLog header line).
> 
> New commits will not start with [smth] in general.  Of course you *can*
> do that, with enough effort.  You can also have two consecutive empty
> lines in your commit messages just fine, but git won't let you without
> a fight.  This is similar.
> 
>> Simply having the Legacy-ID in the commit message will be a visible
>> difference from new commit messages.  But I'm happy it's desirable to have
>> it there, because references to SVN revisions in list archives are so
>> common and having it in the commit messages makes it very quick and easy
>> to map to a git commit id, without needing any on-the-side lists of commit
>> mappings or other tools.
> 
> Yes.  Either in the subject line, or later in the commit message (as
> with git-svn).  We can quibble about where is best, but (hopefully)
> everyone agrees we need the SVN id *somewhere* :-)
> 
> 
> Segher
> 

With my trial reposurgeon conversion:

	git log --all --oneline --grep="Legacy-ID: <number>$"

-all searches all branches, the trailing $ ensures an exact match; 
--oneline just prints the short summary.

eg.
$ git log --oneline --all --grep="Legacy-ID: 278572$"
44e365ba66c [backport] quadmath.h (M_Eq, [...]): Use two more decimal 
places.

No need to put this in the summary.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 03/12/2019 09:44, Richard Earnshaw (lists) wrote:
> On 03/12/2019 00:47, Segher Boessenkool wrote:
>> On Mon, Dec 02, 2019 at 08:24:47PM +0000, Joseph Myers wrote:
>>> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
>>>
>>>> Sure; I'm just saying rewriting old commit messages in such a style 
>>>> that
>>>> they keep standing out from new ones is a bit of a weird choice.
>>>
>>> I'd say the rewrites make them stand out *less* (if people avoid having
>>> new commit messages whose summary line is just the ChangeLog header 
>>> line).
>>
>> New commits will not start with [smth] in general.  Of course you *can*
>> do that, with enough effort.  You can also have two consecutive empty
>> lines in your commit messages just fine, but git won't let you without
>> a fight.  This is similar.
>>
>>> Simply having the Legacy-ID in the commit message will be a visible
>>> difference from new commit messages.  But I'm happy it's desirable to 
>>> have
>>> it there, because references to SVN revisions in list archives are so
>>> common and having it in the commit messages makes it very quick and easy
>>> to map to a git commit id, without needing any on-the-side lists of 
>>> commit
>>> mappings or other tools.
>>
>> Yes.  Either in the subject line, or later in the commit message (as
>> with git-svn).  We can quibble about where is best, but (hopefully)
>> everyone agrees we need the SVN id *somewhere* :-)
>>
>>
>> Segher
>>
> 
> With my trial reposurgeon conversion:
> 
>      git log --all --oneline --grep="Legacy-ID: <number>$"
> 
> -all searches all branches, the trailing $ ensures an exact match; 
> --oneline just prints the short summary.
> 
> eg.
> $ git log --oneline --all --grep="Legacy-ID: 278572$"
> 44e365ba66c [backport] quadmath.h (M_Eq, [...]): Use two more decimal 
> places.
> 
> No need to put this in the summary.

Or even:

git config alias.svn-rev '!f() { rev=$1; shift; git log --all --oneline 
--grep="Legacy-ID: $rev$" ${@}; } ; f'

now you can do

$ git svn-rev 278572 --oneline
44e365ba66c [backport] quadmath.h (M_Eq, [...]): Use two more decimal 
places.

or

$ git svn-rev 278572
commit 44e365ba66c6ccf6cb05f75771946d2992bd51c4
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Nov 21 18:07:15 2019 +0100

     [backport] quadmath.h (M_Eq, [...]): Use two more decimal places.

             Backported from mainline
             2019-08-02  Jakub Jelinek  <jakub@redhat.com>

             * quadmath.h (M_Eq, M_LOG2Eq, M_LOG10Eq, M_LN2q, M_LN10q, 
M_PIq,
             M_PI_2q, M_PI_4q, M_1_PIq, M_2_PIq, M_2_SQRTPIq, M_SQRT2q,
             M_SQRT1_2q): Use two more decimal places.

     Legacy-ID: 278572

R.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 02/12/2019 10:54, Richard Earnshaw (lists) wrote:
> On 19/11/2019 14:56, Jason Merrill wrote:
>> On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) <
>> Richard.Earnshaw@arm.com> wrote:
>>
>>> On 18/11/2019 20:53, Jason Merrill wrote:
>>>> On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool <
>>>> segher@kernel.crashing.org> wrote:
>>>>
>>>>> On Mon, Nov 18, 2019 at 07:21:22PM +0000, Richard Earnshaw (lists)
>>> wrote:
>>>>>> On 18/11/2019 18:53, Segher Boessenkool wrote:
>>>>>>> PR target/92140: clang vs gcc optimizing with adc/sbb
>>>>>>> PR fortran/91926: assumed rank optional
>>>>>>> PR tree-optimization/91532: [SVE] Redundant predicated store in
>>>>> gcc.target/aarch64/fmla_2.c
>>>>>>> PR tree-optimization/92161: ICE in
>>>>>>> vect_get_vec_def_for_stmt_copy, at
>>>>> tree-vect-stmts.c:1687
>>>>>>> PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction,
>>>>> at tree-vect-loop.c:4252
>>>>>>> PR c++/92015: internal compiler error: in
>>>>>>> cxx_eval_array_reference, at
>>>>> cp/constexpr.c:2568
>>>>>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
>>>>> optabs-tree.c:81
>>>>>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at
>>>>> optabs-tree.c:81
>>>>>>> PR fortran/92174: runtime error: index 15 out of bounds for type
>>>>> 'gfc_expr *[15]
>>>>>>>
>>>>>>> Most of these aren't helpful at all, and none of these are good
>>>>>>> commit
>>>>>>> summaries.  The PR92173 one actually has identical commit messages
>>> btw,
>>>>>>> huh.  Ah, the second one (r277288) has the wrong changelog, but
>>>>>>> in the
>>>>>>> actual changelog file as well, not something any tool could fix
>>>>>>> up (or
>>>>>>> have we reached the singularity?)
>>>>>>
>>>>>> Identical commits are normally from where the same commit is made to
>>>>>> multiple branches.  It's not uncommon to see this when bugs are
>>>>>> fixed.
>>>>>
>>>>> This is an actual mistake.  The commits are not identical at all, just
>>>>> the commit messages are (and the changelog entries, too).  Not
>>>>> something
>>>>> that happens to ften, but of course I hit it in the first random
>>>>> thing I
>>>>> pick :-)
>>>>>
>>>>>> Ultimately the question here is whether something like the above is
>>> more
>>>>>> or less useful than what we have today, which is summary lines of the
>>>>> form:
>>>>>>
>>>>>> <date> <user> <email>
>>>>>
>>>>> I already said I would prefer things like
>>>>>    Patch related to PR323
>>>>> as the patch subject lines.  No one argues that the current state of
>>>>> affairs is good.  I argue that replacing this with often wrong and
>>>>> irrelevant information isn't the best we can do.
>>>>>
>>>>
>>>> How about using the first line that isn't a ChangeLog date/author line,
>>>> without trying to rewrite/augment it?
>>>>
>>>> Jason
>>>>
>>>
>>> It would certainly be another way of doing it.  Sometimes it would
>>> produce almost the same as an unadulterated PR; sometimes it would
>>> produce something more meaningful and sometimes it would be pretty
>>> useless.  It probably would hit more cases than my current script in
>>> that it wouldn't require the commit to mention a PR in it.
>>>
>>> The main problem is that the first line is often incomplete, and much of
>>> it is also wasted with elements like the full path to a file that is
>>> quite deep in the tree.  Lets take a quick example (the first I found in
>>> the dump I have).
>>>
>>> 1998-12-17  Vladimir N. Makarov  <vmakarov@cygnus.com>
>>>          * config/i60/i960.md (extendqihi2): Fix typo (usage ','
>>> instead of
>>>          ';').
>>> 1998-12-17  Michael Tiemann  <tiemann@axon.cygnus.com>
>>>          * i960.md (extend*, zero_extend*): Don't generate rtl that
>>> looks
>>>          like (subreg:SI (reg:SI N) 0), because it's wrong, and it hides
>>>          optimizations from the combiner.
>>>
>>> Firstly, this example misses a blank line between the author and the
>>> change message itself, which makes distinguishing between this and the
>>> multiple authors case harder.  Secondly, the entry really spans two
>>> lines and cutting it off at the end of the first line would be, well a
>>> bit odd.  We could try to piece things together more, by combining lines
>>> until we find a sentence end ( \.$ or \.\s\s ), and we could also strip
>>> off more of the path components to just leave the name of the file
>>> committed.  For example,
>>>
>>> i960.md (extendqihi2): Fix typo (usage ',' instead of ';').
>>>
>>> That might work better, but obviously it's harder to handle and thus
>>> more likely to create erroneous summaries.
>>>
>>
>> Yep. I don't think we need to worry about getting optimal one-line
>> summaries for ancient commits; something reasonably unique should be
>> plenty.
>>
> 
> Attached is the latest version of my script.  I used (very nearly) this
> to produce a conversion over the weekend and I've uploaded that here:
> 
> https://gitlab.com/rearnsha/gcc-trial-20191130
> 
> Note, that I might blow this away at any time.  IT IS NOT A FINAL
> CONVERSION.
> 
> Some other things to note:
> - there are a number of known issues with the version of reposurgeon
> used for this that are being worked on
>   - emptycommit-* tags - my control script was out-of-date
>   - *deleted* branches - this is being worked on
>   - weird dependencies around merges - this is being worked on
>   - author attributions are sometimes incorrect - reported
> 

I've just pushed a new trial conversion:

https://gitlab.com/rearnsha/gcc-trial2-20191130

The main differences between this and the previous trial are:
- The author attributions should now be fixed, please let me know if you
see any anomalies in this respect.
- the emptycommit-* tags/branches are now gone.
- the 'tags' used for revert and backport now use more gittish style
revert: and backport:
- the log entries for c++ style functions containing :: are now handled
correctly by my summary generation script.

Other issues are still being worked on.

R.

> The main difference between the attached script and the one I used for
> this conversion is that ChangeLog change that contain :: inside a
> function list is now handled correctly, resulting in a number of cases
> that were previously being missed now being correctly handled.
> 
> Choices I made:
> - When a PR is used to derive the summary, I prefix this with 're' (as
> in the Latin 'in re'.
> - long change hunks produce poor summaries.  To reduce the overhead:
>   - path names are removed, leaving just the final file name
>   - multiple files are replaced with [...] after the first filename
>   - similarly, multiple function names are replaced with [...]
>   - very long comments are truncated, preferably at the strongest
>     punctuation mark, but sometimes after key words, such as 'if',
>     'when', 'unless' and a few more.  Ultimately, if the line is
>     still too long, we just break after an arbitrary space.
> - Where possible useful summary lines that appear after an author,
>   attribution are hoisted as a summary.
> - certain key words in otherwise not very useful summary lines are
>   also spotted and used to add [revert] or [backport] annotations to
>   the summary.
> 
> No changes are made to the main commit log, if we add a new summary
> line, the entire original text is kept.
> 
> An example of a summary produced by this is for the commit to r278572,
> where the original log entry is:
> 
> 
>         Backported from mainline
>         2019-08-02  Jakub Jelinek  <jakub@redhat.com>
> 
>         * quadmath.h (M_Eq, M_LOG2Eq, M_LOG10Eq, M_LN2q, M_LN10q, M_PIq,
>         M_PI_2q, M_PI_4q, M_1_PIq, M_2_PIq, M_2_SQRTPIq, M_SQRT2q,
>         M_SQRT1_2q): Use two more decimal places.
> 
> And the script then generates:
> 
> [backport] quadmath.h (M_Eq, [...]): Use two more decimal places.
> 
> as the summary.
> 
> R.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
> I've just pushed a new trial conversion:
>
> https://gitlab.com/rearnsha/gcc-trial2-20191130
>
> The main differences between this and the previous trial are:
> - The author attributions should now be fixed, please let me know if you
> see any anomalies in this respect.
> - the emptycommit-* tags/branches are now gone.
> - the 'tags' used for revert and backport now use more gittish style
> revert: and backport:
> - the log entries for c++ style functions containing :: are now handled
> correctly by my summary generation script.
>
> Other issues are still being worked on.

There's a bogus libstdc++ directory at the top level. That hasn't been
present for nearly 20 years, so some commit that should have deleted
it seems to be missing or incorrect.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
> > I've just pushed a new trial conversion:
> >
> > https://gitlab.com/rearnsha/gcc-trial2-20191130
> >
> > The main differences between this and the previous trial are:
> > - The author attributions should now be fixed, please let me know if you
> > see any anomalies in this respect.
> > - the emptycommit-* tags/branches are now gone.
> > - the 'tags' used for revert and backport now use more gittish style
> > revert: and backport:
> > - the log entries for c++ style functions containing :: are now handled
> > correctly by my summary generation script.
> >
> > Other issues are still being worked on.
>
> There's a bogus libstdc++ directory at the top level. That hasn't been
> present for nearly 20 years, so some commit that should have deleted
> it seems to be missing or incorrect.

It was removed by r39445 i.e. this commit in the current Git mirror:

commit 1030d23bf251914e12fc8c9d521e334e1f445afc
Author: mmitchel <mmitchel@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Mon Feb 5 01:38:47 2001 +0000

            Remove V2 C++ library.
            * configure.in: Remove --enable-libstdcxx_v3 support.

            * Makefile.in (site.exp): Always set HAVE_LIBSTDCXX_V3.
            * configure.in: Remove --enable-libstdcxx_v3 support.
            * configure: Regenerated.


    git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@39445
138bc75d-0d04-0410-961f-82ee72b054a4

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 05/12/2019 10:32, Jonathan Wakely wrote:
> On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>
>> On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
>>> I've just pushed a new trial conversion:
>>>
>>> https://gitlab.com/rearnsha/gcc-trial2-20191130
>>>
>>> The main differences between this and the previous trial are:
>>> - The author attributions should now be fixed, please let me know if you
>>> see any anomalies in this respect.
>>> - the emptycommit-* tags/branches are now gone.
>>> - the 'tags' used for revert and backport now use more gittish style
>>> revert: and backport:
>>> - the log entries for c++ style functions containing :: are now handled
>>> correctly by my summary generation script.
>>>
>>> Other issues are still being worked on.
>>
>> There's a bogus libstdc++ directory at the top level. That hasn't been
>> present for nearly 20 years, so some commit that should have deleted
>> it seems to be missing or incorrect.
> 
> It was removed by r39445 i.e. this commit in the current Git mirror:
> 
> commit 1030d23bf251914e12fc8c9d521e334e1f445afc
> Author: mmitchel <mmitchel@138bc75d-0d04-0410-961f-82ee72b054a4>
> Date:   Mon Feb 5 01:38:47 2001 +0000
> 
>              Remove V2 C++ library.
>              * configure.in: Remove --enable-libstdcxx_v3 support.
> 
>              * Makefile.in (site.exp): Always set HAVE_LIBSTDCXX_V3.
>              * configure.in: Remove --enable-libstdcxx_v3 support.
>              * configure: Regenerated.
> 
> 
>      git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@39445
> 138bc75d-0d04-0410-961f-82ee72b054a4
> 

Ok, this is one to keep an eye on.  There are a number of anomalous 
commmits at present, which Eric is working on with a new approach to 
replaying the SVN data into reposurgeon.  Once that is done we're hoping 
that this sort of problem will go away.  (of course, if it doesn't then 
the chances are we won't be using reposurgeon for the conversion at all).

This repo conversion is really for checking that the summaries I'm 
generating are not just garbled, and the authors problem from the 
previous trial are now fixed.

R.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 5 Dec 2019 at 10:36, Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 05/12/2019 10:32, Jonathan Wakely wrote:
> > On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >>
> >> On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
> >>> I've just pushed a new trial conversion:
> >>>
> >>> https://gitlab.com/rearnsha/gcc-trial2-20191130
> >>>
> >>> The main differences between this and the previous trial are:
> >>> - The author attributions should now be fixed, please let me know if you
> >>> see any anomalies in this respect.
> >>> - the emptycommit-* tags/branches are now gone.
> >>> - the 'tags' used for revert and backport now use more gittish style
> >>> revert: and backport:
> >>> - the log entries for c++ style functions containing :: are now handled
> >>> correctly by my summary generation script.
> >>>
> >>> Other issues are still being worked on.
> >>
> >> There's a bogus libstdc++ directory at the top level. That hasn't been
> >> present for nearly 20 years, so some commit that should have deleted
> >> it seems to be missing or incorrect.
> >
> > It was removed by r39445 i.e. this commit in the current Git mirror:
> >
> > commit 1030d23bf251914e12fc8c9d521e334e1f445afc
> > Author: mmitchel <mmitchel@138bc75d-0d04-0410-961f-82ee72b054a4>
> > Date:   Mon Feb 5 01:38:47 2001 +0000
> >
> >              Remove V2 C++ library.
> >              * configure.in: Remove --enable-libstdcxx_v3 support.
> >
> >              * Makefile.in (site.exp): Always set HAVE_LIBSTDCXX_V3.
> >              * configure.in: Remove --enable-libstdcxx_v3 support.
> >              * configure: Regenerated.
> >
> >
> >      git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@39445
> > 138bc75d-0d04-0410-961f-82ee72b054a4
> >
>
> Ok, this is one to keep an eye on.  There are a number of anomalous
> commmits at present, which Eric is working on with a new approach to
> replaying the SVN data into reposurgeon.  Once that is done we're hoping
> that this sort of problem will go away.  (of course, if it doesn't then
> the chances are we won't be using reposurgeon for the conversion at all).

OK. There are several other deletions missing, as I see these in your
conversion which aren't on trunk (paths relative to the libstdc++-v3
dir because that's all I'm checking):

Only in ./config/abi/post: solaris2.8
Only in ./config/os: irix
Only in ./config/os: osf
Only in ./config/os/solaris: solaris2.8
Only in ./include/ext/pb_ds/detail/cc_hash_table_map_: standard_policies.hpp
Only in ./include/ext/pb_ds/detail/gp_hash_table_map_: standard_policies.hpp
Only in ./src/c++98: compatibility-parallel_list-2.cc
Only in ./src/c++98: compatibility-parallel_list.cc
Only in ./testsuite/20_util: is_explicitly_convertible
Only in ./testsuite/26_numerics: cmath
Only in ./testsuite/28_regex/algorithms: 02_match
Only in ./testsuite/28_regex/basic_regex: regex.cc
Only in ./testsuite/28_regex/headers: 04_header


> This repo conversion is really for checking that the summaries I'm
> generating are not just garbled, and the authors problem from the
> previous trial are now fixed.

OK, apart from the artefacts caused by me not knowing my own email
address (discussed off-list), those look good to me.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 5 Dec 2019 at 10:41, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Thu, 5 Dec 2019 at 10:36, Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
> >
> > On 05/12/2019 10:32, Jonathan Wakely wrote:
> > > On Thu, 5 Dec 2019 at 10:25, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > >>
> > >> On Wed, 4 Dec 2019 at 23:52, Richard Earnshaw (lists) wrote:
> > >>> I've just pushed a new trial conversion:
> > >>>
> > >>> https://gitlab.com/rearnsha/gcc-trial2-20191130
> > >>>
> > >>> The main differences between this and the previous trial are:
> > >>> - The author attributions should now be fixed, please let me know if you
> > >>> see any anomalies in this respect.
> > >>> - the emptycommit-* tags/branches are now gone.
> > >>> - the 'tags' used for revert and backport now use more gittish style
> > >>> revert: and backport:
> > >>> - the log entries for c++ style functions containing :: are now handled
> > >>> correctly by my summary generation script.
> > >>>
> > >>> Other issues are still being worked on.
> > >>
> > >> There's a bogus libstdc++ directory at the top level. That hasn't been
> > >> present for nearly 20 years, so some commit that should have deleted
> > >> it seems to be missing or incorrect.
> > >
> > > It was removed by r39445 i.e. this commit in the current Git mirror:
> > >
> > > commit 1030d23bf251914e12fc8c9d521e334e1f445afc
> > > Author: mmitchel <mmitchel@138bc75d-0d04-0410-961f-82ee72b054a4>
> > > Date:   Mon Feb 5 01:38:47 2001 +0000
> > >
> > >              Remove V2 C++ library.
> > >              * configure.in: Remove --enable-libstdcxx_v3 support.
> > >
> > >              * Makefile.in (site.exp): Always set HAVE_LIBSTDCXX_V3.
> > >              * configure.in: Remove --enable-libstdcxx_v3 support.
> > >              * configure: Regenerated.
> > >
> > >
> > >      git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@39445
> > > 138bc75d-0d04-0410-961f-82ee72b054a4
> > >
> >
> > Ok, this is one to keep an eye on.  There are a number of anomalous
> > commmits at present, which Eric is working on with a new approach to
> > replaying the SVN data into reposurgeon.  Once that is done we're hoping
> > that this sort of problem will go away.  (of course, if it doesn't then
> > the chances are we won't be using reposurgeon for the conversion at all).
>
> OK. There are several other deletions missing, as I see these in your
> conversion which aren't on trunk (paths relative to the libstdc++-v3
> dir because that's all I'm checking):
>
> Only in ./config/abi/post: solaris2.8

Should have been removed by r185392 which is present as
ec7b5a78e90a4245792f8d9a9288e9f98f904f87

> Only in ./config/os: irix

Should have been removed by r185390 aka 9cf50112d877a9b35faa68889ab5ba4ee73291b2

> Only in ./config/os: osf

Should have been removed by r185240 aka ed3aca91ef9c7f81b7f7a66ae0b936fde69d8b63

> Only in ./include/ext/pb_ds/detail/cc_hash_table_map_: standard_policies.hpp
> Only in ./include/ext/pb_ds/detail/gp_hash_table_map_: standard_policies.hpp

Both removed by r194107 which is missing.

> Only in ./src/c++98: compatibility-parallel_list-2.cc
> Only in ./src/c++98: compatibility-parallel_list.cc

Both renamed by r191837 aka 6099a280b4fceb232da81feb92f95b3d889f29c9

> Only in ./testsuite/20_util: is_explicitly_convertible

Removed by r186617 which is missing.

> Only in ./testsuite/26_numerics: cmath

Renamed by r186445 aka 99686a77aa36b93313ae29e4fffd2ae3ed7b549e

> Only in ./testsuite/28_regex/algorithms: 02_match

Removed by r188923 aka 7202cd20761d4dee77cdbcb677b0b667c83ddea2

> Only in ./testsuite/28_regex/basic_regex: regex.cc

Renamed by r192146 aka b70e38df276382a62d4dc13adf0751f435cc990b


> > This repo conversion is really for checking that the summaries I'm
> > generating are not just garbled, and the authors problem from the
> > previous trial are now fixed.
>
> OK, apart from the artefacts caused by me not knowing my own email
> address (discussed off-list), those look good to me.

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 5 Dec 2019, Richard Earnshaw (lists) wrote:

> Ok, this is one to keep an eye on.  There are a number of anomalous commmits
> at present, which Eric is working on with a new approach to replaying the SVN
> data into reposurgeon.  Once that is done we're hoping that this sort of
> problem will go away.  (of course, if it doesn't then the chances are we won't
> be using reposurgeon for the conversion at all).

I think we currently have the following reposurgeon issues open for cases 
where the present code results in incorrect tree contents and we're hoping 
the new code will fix that (or make it much easier to find and fix the 
bugs).  These are the issues that are most critical for being able to use 
reposurgeon for the conversion.

https://gitlab.com/esr/reposurgeon/issues/167
https://gitlab.com/esr/reposurgeon/issues/171
https://gitlab.com/esr/reposurgeon/issues/172
https://gitlab.com/esr/reposurgeon/issues/178

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Eric S. Raymond]

Richard Earnshaw (lists) <Richard.Earnshaw@arm.com>:
> Ok, this is one to keep an eye on.  There are a number of anomalous commmits
> at present, which Eric is working on with a new approach to replaying the
> SVN data into reposurgeon.  Once that is done we're hoping that this sort of
> problem will go away.

Best case is it just goes away.  Worst case is we'll need to figure out what surgical commands
need to be patched into the recipe to deal with the remaining anomalies.

I suspect the latter, in particular that we're going to end up needing
to do something manually around r14877.  Iy might be a trivial tweak to
the splice command I commented out.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> I think we currently have the following reposurgeon issues open for cases 
> where the present code results in incorrect tree contents and we're hoping 
> the new code will fix that (or make it much easier to find and fix the 
> bugs).  These are the issues that are most critical for being able to use 
> reposurgeon for the conversion.
> 
> https://gitlab.com/esr/reposurgeon/issues/167
> https://gitlab.com/esr/reposurgeon/issues/171
> https://gitlab.com/esr/reposurgeon/issues/172
> https://gitlab.com/esr/reposurgeon/issues/178

I'm aware these are the real blockers.

I was much more worried about the conversion before we figured out
that most of the remaining content mismatches seem to radiate out from
something weird that happened at r14877.  That's early enough that a
leading-segment load including it doesn't take forever.  Which means
it's practical to do detailed forensics on the defect even if you don't
have handy an EC12 instance with ridiculo-humongous amonts of RAM.

Now I'm pretty certain we can finish this.  A matter of when, not if.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 5 Dec 2019, Eric S. Raymond wrote:

> I was much more worried about the conversion before we figured out
> that most of the remaining content mismatches seem to radiate out from
> something weird that happened at r14877.  That's early enough that a
> leading-segment load including it doesn't take forever.  Which means
> it's practical to do detailed forensics on the defect even if you don't
> have handy an EC12 instance with ridiculo-humongous amonts of RAM.

I just tried a leading-segment load up to r14877, but it didn't reproduce 
the problems I see with r14877 in a full repository conversion - it seems 
the combination with something later in the history may be necessary to 
reproduce the issue.  (With trunk-deletion-and-recreation being an obvious 
candidate, since *some* content problems definitely first appear at such 
commits.)

If it's necessary to bisect to find what leading segment produces that 
problem (if it still appears with the new SVN dump reader), obviously 
things can be speeded up for the bisection by omitting slow things such as 
the deletion of emptycommit tags (a minimal gcc.lift makes sense for such 
a bisection anyway).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> I just tried a leading-segment load up to r14877, but it didn't reproduce 
> the problems I see with r14877 in a full repository conversion - it seems 
> the combination with something later in the history may be necessary to 
> reproduce the issue.

Great :-(

Well, there's a bisection-like strategy for finding the minimum
leading segment that produces misbehavior.  My conversion crew will
apply it as hard as we need to to get the job done.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 5 Dec 2019, Eric S. Raymond wrote:

> Joseph Myers <joseph@codesourcery.com>:
> > I just tried a leading-segment load up to r14877, but it didn't reproduce 
> > the problems I see with r14877 in a full repository conversion - it seems 
> > the combination with something later in the history may be necessary to 
> > reproduce the issue.
> 
> Great :-(
> 
> Well, there's a bisection-like strategy for finding the minimum
> leading segment that produces misbehavior.  My conversion crew will
> apply it as hard as we need to to get the job done.

I've now provided a reduced synthetic test (7 commits) for the issue 
observed at r14877, in issue 172.  It wouldn't surprise me if a fix for 
this synthetic test fixes both issues 171 and 172 (and it wouldn't 
surprise me if it's fixed in the new SVN dump reader).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 5 Dec 2019, Joseph Myers wrote:

> On Thu, 5 Dec 2019, Eric S. Raymond wrote:
> 
> > Joseph Myers <joseph@codesourcery.com>:
> > > I just tried a leading-segment load up to r14877, but it didn't reproduce 
> > > the problems I see with r14877 in a full repository conversion - it seems 
> > > the combination with something later in the history may be necessary to 
> > > reproduce the issue.
> > 
> > Great :-(
> > 
> > Well, there's a bisection-like strategy for finding the minimum
> > leading segment that produces misbehavior.  My conversion crew will
> > apply it as hard as we need to to get the job done.
> 
> I've now provided a reduced synthetic test (7 commits) for the issue 
> observed at r14877, in issue 172.  It wouldn't surprise me if a fix for 
> this synthetic test fixes both issues 171 and 172 (and it wouldn't 
> surprise me if it's fixed in the new SVN dump reader).

And given the synthetic test I've added to issue 178, I suspect the same 
problem is behind at least some of the missing file/directory deletions as 
well.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> On Thu, 5 Dec 2019, Eric S. Raymond wrote:
> 
> > Joseph Myers <joseph@codesourcery.com>:
> > > I just tried a leading-segment load up to r14877, but it didn't reproduce 
> > > the problems I see with r14877 in a full repository conversion - it seems 
> > > the combination with something later in the history may be necessary to 
> > > reproduce the issue.
> > 
> > Great :-(
> > 
> > Well, there's a bisection-like strategy for finding the minimum
> > leading segment that produces misbehavior.  My conversion crew will
> > apply it as hard as we need to to get the job done.
> 
> I've now provided a reduced synthetic test (7 commits) for the issue 
> observed at r14877, in issue 172.  It wouldn't surprise me if a fix for 
> this synthetic test fixes both issues 171 and 172 (and it wouldn't 
> surprise me if it's fixed in the new SVN dump reader).

If not, I think it soon will be. I expect that little synthetic test
to help a lot.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Eric S. Raymond]

Joseph Myers <joseph@codesourcery.com>:
> On Thu, 5 Dec 2019, Joseph Myers wrote:
> 
> > On Thu, 5 Dec 2019, Eric S. Raymond wrote:
> > 
> > > Joseph Myers <joseph@codesourcery.com>:
> > > > I just tried a leading-segment load up to r14877, but it didn't reproduce 
> > > > the problems I see with r14877 in a full repository conversion - it seems 
> > > > the combination with something later in the history may be necessary to 
> > > > reproduce the issue.
> > > 
> > > Great :-(
> > > 
> > > Well, there's a bisection-like strategy for finding the minimum
> > > leading segment that produces misbehavior.  My conversion crew will
> > > apply it as hard as we need to to get the job done.
> > 
> > I've now provided a reduced synthetic test (7 commits) for the issue 
> > observed at r14877, in issue 172.  It wouldn't surprise me if a fix for 
> > this synthetic test fixes both issues 171 and 172 (and it wouldn't 
> > surprise me if it's fixed in the new SVN dump reader).
> 
> And given the synthetic test I've added to issue 178, I suspect the same 
> problem is behind at least some of the missing file/directory deletions as 
> well.

Likely, yes.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Commit messages and the move to git

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:

> I've attached a sample from the start of the fixed list - the full list is far
> too big to post to give a flavour of how the script currently works.  Note
> that annotations of the form [checkme: ....] in the summary are for diagnostic
> purposes.  These are where heuristics suggest that there's a higher than
> normal chance that the PR number is incorrect and that manual auditing is
> recommended.  Such annotations would not be appropriate in the final
> conversion.

Concretely, here is the current list of 664 checkme: annotations where 
something was suspicious about the PR number (either component mismatch or 
resolved as INVALID).  Would some people like to volunteer to pick up 
sections of this list and, for their section, produce a list of SVN 
revisions (at the end of the checkme line) for which the PR number appears 
to be correct, and a list of mappings from SVN revision to correct PR 
number when the PR number appears to be wrong?  For any that don't get 
reviewed like that we can easily make the script, for the final 
conversion, decline to add a new summary line for any commit where the PR 
number is suspicious.

-- 
Joseph S. Myers
joseph@codesourcery.com

[-- Attachment #2: Type: text/plain, Size: 74286 bytes --]

re PR fortran/13911 ([g77]  Cannot initialize variables with declation as allowed by g77 [checkme: g++ SVN r17128])
re PR c++/2823 (kde2/artsd miscompilation (part 1) [checkme: g++ SVN r42648])
re PR c++/2823 (kde2/artsd miscompilation (part 1) [checkme: g++ SVN r42650])
re PR c++/2936 (gcc gives me an internal error when compiling mozilla with --enable-optimization="-O3" [checkme: g++ SVN r42704])
re PR c++/2936 (gcc gives me an internal error when compiling mozilla with --enable-optimization="-O3" [checkme: g++ SVN r42705])
re PR c++/4476 (g++ does not parse the definition of friend function within a class properly [checkme: g++ SVN r46226])
re PR c++/4206 (ICE with switch in while [checkme: g++ SVN r46992])
re PR c++/3154 (Tree check: expected class 't', have 'd' (type_decl) in is_aggr_type, at cp/init.c:1435 [checkme: g++ SVN r47047])
re PR c++/3145 (virtual inheritance still creates wrong code [checkme: g++ SVN r47316])
re PR c++/3381 (explicit template instantations fail with absolutely qualified names [checkme: g++ SVN r47546])
re PR debug/5163 (Internal compiler error in add_abstract_origin_attribute, at dwarf2out.c:9296 [checkme: c SVN r48302])
re PR fortran/6138 (Incorrect access of integer*1 variables on PA [checkme: f SVN r52630])
re PR fortran/6138 (Incorrect access of integer*1 variables on PA [checkme: f SVN r52631])
re PR libffi/10610 ([powerpc-linux] 230 testsuite failures due to alignment errors [checkme: libgcj SVN r73019])
re PR libffi/10610 ([powerpc-linux] 230 testsuite failures due to alignment errors [checkme: libgcj SVN r73021])
re PR rtl-optimization/13024 (gcj can't build current rhug [checkme: java SVN r73752])
backport: re PR rtl-optimization/12816 (internal compiler error pari-2.1.5/Olinux-i686 [checkme: c++ SVN r75851])
revert: re PR tree-optimization/16115 (double-destruction problem with argument passing via temporary (breaks auto_ptr) [checkme: c++ SVN r84147])
re PR tree-optimization/15262 ([tree-ssa] Alias analyzer cannot handle addressable fields [checkme: c SVN r86398])
re PR rtl-optimization/15857 (Wrong code with optimization >= -O1 [checkme: c++ SVN r87429])
re PR c/16403 (Floating-point assignment to int is inconsistent [checkme: INVALID SVN r94142])
re PR c++/20505 (internal error when compiling with -ggdb2 and no error with -ggdb1 [checkme: debug SVN r97528])
re PR libgcj/21058 (fragile libgcj link process omits some inner classes [checkme: libgj SVN r102140])
re PR rtl-optimization/19210 (not using do-loop for some loops [checkme: tree-optimization SVN r102225])
re PR tree-optimization/21562 (Quiet bad codegen (unrolling + tail call interaction) [checkme: c SVN r103245])
re PR boehm-gc/23662 (Binaries generated by arm-linux-gcj segfault on execution on arm target [checkme: libgcj SVN r103945])
re PR boehm-gc/23662 (Binaries generated by arm-linux-gcj segfault on execution on arm target [checkme: libgcj SVN r103946])
re PR c++/7874 (g++ finds friend functions defined in class-definition but not declared in the enclosing namespace [checkme: g++ SVN r104188])
re PR c/21419 (Accepts writting to const via asm [checkme: tree-optimization SVN r104991])
re PR awt/26641 (AWT mouse event handling regression [checkme: libgcj SVN r112464])
re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114637])
re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114639])
re PR middle-end/25505 (gcc uses way too much stack space for this code [checkme: c++ SVN r116634])
re PR libstdc++/39238 (trunk revision 144279 - cfenv:54: error: ‘::fenv_t’ has not been declared [checkme: fortran SVN r120056])
re PR cp-tools/30707 (gjavah cannot handle more than one CLASS [checkme: libgcj SVN r121664])
re PR cp-tools/30707 (gjavah cannot handle more than one CLASS [checkme: libgcj SVN r121665])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121666])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121667])
re PR debug/33739 (Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin [checkme: fortran SVN r130244])
re PR c++/31863 (g++-4.1: out of memory with -O1/-O2 [checkme: middle-end SVN r131405])
re PR c/34601 (ICE with undefined enum [checkme: middle-end SVN r131506])
re PR middle-end/34668 (ICE in find_compatible_field with -combine [checkme: c SVN r131572])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131649])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131670])
re PR tree-optimization/34885 (ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574 [checkme: c SVN r131694])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131719])
re PR c++/34953 (ICE on destructor + noreturn-function at -O3 [checkme: middle-end SVN r131782])
re PR translation/35002 (Incorrect spelling of "hottest" [checkme: c SVN r131940])
re PR driver/30330 (-Wdeprecated is not documented [checkme: documentation SVN r132131])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132382])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132493])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132494])
re PR tree-optimization/33512 (Simple bitwise simplification missed [checkme: rtl-opt SVN r132575])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132601])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132602])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132603])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132821])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133106])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133108])
re PR classpath/35422 (no generated javadoc of java/util/concurrent from external/jsr166 [checkme: tree-opt SVN r133144])
re PR classpath/35422 (no generated javadoc of java/util/concurrent from external/jsr166 [checkme: tree-opt SVN r133163])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133195])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133220])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r133470])
re PR rtl-optimization/19580 (missed load/store motion [checkme: tree-optimization SVN r133683])
re PR preprocessor/34866 (valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c [checkme: libcpp SVN r134421])
re PR preprocessor/15500 (gcc ignores locale when converting wide string literals to wchar_t strings [checkme: libcpp SVN r134441])
re PR preprocessor/33415 (Can't compile .cpp file with UTF-8 BOM. [checkme: libcpp SVN r134507])
re PR c/36021 (__attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault [checkme: middle-end SVN r134595])
re PR c/36021 (__attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault [checkme: middle-end SVN r134596])
re PR c++/35652 (offset warning should be given in the front-end [checkme: c SVN r134714])
re PR fortran/36117 (Use MPFR for bessel function (optimization, rejects valid F2008) [checkme: middle-end SVN r135113])
re PR c++/36185 (wrong code with  -O2 -fgcse-sm [checkme: rtl-optimization SVN r135159])
re PR c++/35336 (Broken diagnostic: 'bit_field_ref' not supported by dump_expr [checkme: middle-end SVN r136662])
re PR c++/36460 (No space between >'s not always handled in C++0x [checkme: c SVN r136919])
re PR middle-end/36571 (Default untyped return for AVR is byte register. [checkme: c SVN r136926])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r136989])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r137001])
re PR tree-optimization/34371 (verify_stmts failed (incorrect sharing of tree nodes) [checkme: fortran SVN r137088])
re PR rtl-optimization/36672 (IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829 [checkme: preprocessor SVN r137581])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r137793])
re PR c++/36852 (Two dimensional array in template method argument list incorrectly interpreted. [checkme: fortran SVN r138072])
re PR c++/36852 (Two dimensional array in template method argument list incorrectly interpreted. [checkme: libfortran SVN r138073])
re PR c++/36852 (Two dimensional array in template method argument list incorrectly interpreted. [checkme: fortran SVN r138170])
re PR c++/36852 (Two dimensional array in template method argument list incorrectly interpreted. [checkme: libfortran SVN r138172])
re PR ada/36957 (ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge [checkme: tree-optimization SVN r138217])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r138293])
re PR middle-end/36633 (warning "array subscript is below array bounds" on delete [] with -O2, -Wall [checkme: c++ SVN r138425])
re PR c++/17880 (-Wsequence-point doesn't warn inside if, while, do conditions, for beg/cond/end expressions etc. [checkme: c SVN r138904])
re PR c++/28152 (Diagnostic about wrong use _Complex prints __complex__ [checkme: c SVN r139097])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r139159])
re PR c++/8895 (ICE on invalid template default value specification [checkme: libgcj SVN r139492])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139784])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139786])
re PR ada/37328 (ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747 [checkme: tree-optimization SVN r139931])
re PR middle-end/18071 (-Winline does not respect -fno-default-inline [checkme: c++ SVN r140418])
re PR fortran/37588 (GENERIC type-bound procedure is not resolved [checkme: c++ SVN r140424])
re PR debug/37410 (DW_TAG_imported_module is not in its DW_TAG_lexical_block [checkme: c++ SVN r140895])
re PR middle-end/29609 (Even with  -O0 -g gcc optimizes a goto away and I cannot debug [checkme: debug SVN r140948])
re PR tree-optimization/37568 (ICE returning a struct [checkme: c++ SVN r141010])
re PR debug/27017 (Debug information for static local class members are not emitted [checkme: c++ SVN r141829])
re PR debug/27574 (MIssing debug info at -O0 for a local variable in a C++ constructor [checkme: c++ SVN r141984])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142840])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142841])
re PR middle-end/36191 (can't use complex in a eh region if non-call-exceptions is enabled [checkme: c++ SVN r142950])
re PR tree-optimization/35805 ([ira] error in start_allocno_priorities, at ira-color.c:1806 [checkme: rtl-optimization SVN r143027])
re PR tree-optimization/38385 (ICE with -O2 -ftree-loop-distribution [checkme: middlend SVN r143291])
re PR c++/38908 (Unexplained "'<anonymous>' is used uninitialized in this function" warning in cc1plus -m64 [checkme: middle-end SVN r143722])
re PR c++/29027 (template conversion specialization found by using declaration [checkme: c SVN r144443])
re PR c++/39409 (internal compiler error: Segmentation fault [checkme: libfortran SVN r144718])
re PR c++/29027 (template conversion specialization found by using declaration [checkme: c SVN r145422])
re PR c++/8781 (Pessimization of C++ (functional) code [checkme: tree-optimization SVN r145533])
re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145569])
backport: re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145574])
re PR middle-end/39614 (Internal error compiling CSiBE [checkme: c SVN r145737])
re PR rtl-optimization/37377 (Bootstrap failure compiling libgcc [checkme: fortran SVN r145965])
re PR c/39928 (gimplify_expr failure [checkme: middle-end SVN r146846])
re PR java/39940 (failure in jc1 on i686-apple-darwin9 host [checkme: tree-optimization SVN r147065])
re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r147659])
re PR middle-end/39834 (verify_cgraph_node failed with -O3 -Winline [checkme: debug SVN r148292])
re PR c++/40389 (optimizer bug (possibly) [checkme: tree-optimization SVN r148458])
re PR c++/40389 (optimizer bug (possibly) [checkme: middle-end SVN r148462])
backport: re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r148469])
re PR c++/40389 (optimizer bug (possibly) [checkme: tree-optimization SVN r148597])
re PR c++/40389 (optimizer bug (possibly) [checkme: middle-end SVN r148601])
re PR c++/40389 (optimizer bug (possibly) [checkme: middle-end SVN r148604])
re PR c++/40492 (ice in create_tmp_var [checkme: tree-optimization SVN r148787])
backport: re PR c++/40492 (ice in create_tmp_var [checkme: tree-optimization SVN r148797])
re PR objc++/28050 (ICE on invalid initializer [checkme: objc SVN r148804])
re PR objc++/28050 (ICE on invalid initializer [checkme: objc SVN r148819])
re PR objc++/28050 (ICE on invalid initializer [checkme: objc SVN r148820])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r149010])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149470])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149499])
re PR c/48388 (libgcc compilation causes a segfault [checkme: middle-end SVN r149516])
re PR middle-end/40867 (FAIL: StackTrace2 output - source compiled test [checkme: java SVN r150376])
re PR c++/41094 (Erroneous optimization of pow() with -ffast-math [checkme: middle-end SVN r150874])
re PR c++/41094 (Erroneous optimization of pow() with -ffast-math [checkme: middle-end SVN r151051])
re PR c++/41094 (Erroneous optimization of pow() with -ffast-math [checkme: middle-end SVN r151052])
re PR debug/40660 (Weird break points with 4.5, works with 4.4 [checkme: fortran SVN r151069])
re PR c/41163 (verify_gimple fails [checkme: middle-end SVN r151122])
re PR c++/41273 (ICE in add_virtual_operand, at tree-ssa-operands.c:638 [checkme: debug SVN r151454])
re PR c++/41144 (ice for legal code with -O2 in get_alias_set [checkme: middle-end SVN r151461])
re PR c/39779 (ICE shifting byte to the right with constant > 7FFFFFFF [checkme: rtl-optimization SVN r151573])
re PR c++/41275 (ICE: expand_expr_real_1, at expr.c:8416 [checkme: middle-end SVN r151631])
re PR c/41935 (ICE : tree check: expected integer_cst, have nop_expr in int_cst_value, at tree.c:8301 [checkme: middle-end SVN r153962])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154061])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154063])
re PR c++/26965 (Unnecessary debug info for unused consts in C++ [checkme: debug SVN r154157])
re PR c++/41961 (Internal error with -O3 and -ftree-parallelize-loops [checkme: tree-optimization SVN r154748])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154878])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154879])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154885])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154965])
re PR libstdc++/42381 (deque shouldn't reserve that much memory [checkme: libsdtc++ SVN r155271])
re PR tree-optimization/42386 (ICE in ipcp_iterate_stage, at ipa-cp.c:766 [checkme: c++ SVN r155321])
re PR rtl-optimization/42589 (bswap optimization does not work for 32bit (but for 64bit) on 64bit registers [checkme: tree-optimization SVN r155588])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r155765])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156010])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156016])
re PR tree-optimization/42685 ("-fcompare-debug failure" with "-O1 -funroll-loops" (2) [checkme: rtl-optimization SVN r156252])
re PR debug/42991 (cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s) [checkme: middle-end SVN r156575])
re PR c/43125 (Revision 156907 failed gcc.dg/attr-used.c [checkme: middle-end SVN r156927])
re PR rtl-optimization/40761 (IRA memory hog for insanely nested loops [checkme: tree-optimization SVN r157225])
re PR rtl-optimization/43058 (var-tracking uses up all virtual memory [checkme: debug SVN r157547])
re PR c/43661 (ice in fold_comparison, at fold-const.c:9579 [checkme: middle-end SVN r157984])
re PR tree-optimization/43611 (ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions [checkme: c++ SVN r158218])
re PR tree-optimization/43611 (ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions [checkme: c++ SVN r158376])
re PR debug/42425 (ICE declaring local class [checkme: lto SVN r158722])
re PR c++/43080 (ICE with anonymous union and -flto [checkme: lto SVN r158723])
re PR c++/40561 (code does not compile -- compiles fine when replacing != with !(==) [checkme: middle-end SVN r158778])
re PR middle-end/43880 (internal compiler error: in make_decl_rtl [checkme: c++ SVN r158824])
re PR middle-end/43880 (internal compiler error: in make_decl_rtl [checkme: c++ SVN r159069])
re PR c/44024 (missed optimization [checkme: middle-end SVN r159205])
re PR middle-end/44104 (New test failures [checkme: debug SVN r159367])
re PR c++/44256 (When using -flto and -fwhole-program the compiler/linker crash [checkme: lto SVN r159779])
re PR c++/41921 (Cross language don't work with typedef unnamed structs [checkme: lto SVN r160226])
re PR c++/41921 (Cross language don't work with typedef unnamed structs [checkme: lto SVN r160227])
re PR middle-end/44536 (OMP: missing error with default(none) [checkme: fortran SVN r160779])
re PR middle-end/44536 (OMP: missing error with default(none) [checkme: fortran SVN r160780])
re PR middle-end/44536 (OMP: missing error with default(none) [checkme: fortran SVN r160783])
re PR lto/44248 (-fcompare-debug failure with -flto/-fwhopr -g [checkme: debug SVN r161056])
backport: re PR middle-end/44104 (New test failures [checkme: debug SVN r161666])
re PR rtl-optimization/44479 (false dependencies are computed after vectorization [checkme: tree-optimization SVN r161802])
re PR c/44828 (possible integer wrong code bug [checkme: middle-end SVN r161869])
re PR c/44828 (possible integer wrong code bug [checkme: middle-end SVN r161942])
re PR c/44828 (possible integer wrong code bug [checkme: middle-end SVN r161956])
re PR fortran/44882 (Bogus types in references with mismatched commons [checkme: tree-optimization SVN r161990])
re PR debug/44689 (-fenable-icf-debug causes segfault in cp_function_decl_explicit_p [checkme: fortran SVN r162052])
re PR c++/36960 (Reference variable in virtually inherited base corrupted under optimization [checkme: tree-optimization SVN r162141])
re PR debug/44971 (-fcompare-debug failure with uninitialized read in walk_gimple_stmt [checkme: middle-end SVN r162329])
re PR c++/43850 (ice: tree code �template_type_parm� is not supported in gimple streams [checkme: lto SVN r162416])
re PR c/45176 (restrict qualifier is not used in a manually unrolled loop [checkme: middle-end SVN r162862])
re PR middle-end/45307 (Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated [checkme: c++ SVN r163380])
re PR middle-end/45307 (Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated [checkme: c++ SVN r163439])
re PR middle-end/45505 (gfortran.dg/pr25923.f90 [checkme: fortran SVN r163949])
re PR c++/45605 (Missed devirtualization [checkme: tree-optimization SVN r164148])
re PR c++/45605 (Missed devirtualization [checkme: tree-optimization SVN r164402])
re PR c++/45605 (Missed devirtualization [checkme: tree-optimize SVN r164438])
re PR libgomp/45838 (FAIL: libgomp.c/pr34513.c execution test [checkme: middle-end SVN r165012])
re PR c/45869 (type mismatch in shift expression produces ice with -O3 and -m32 [checkme: middle-end SVN r165108])
re PR c/45869 (type mismatch in shift expression produces ice with -O3 and -m32 [checkme: middle-end SVN r165113])
re PR rtl-optimization/45903 (unnecessary load of 32/64bit variable when only 8 bits are needed [checkme: tree-optimization SVN r165200])
re PR rtl-optimization/45903 (unnecessary load of 32/64bit variable when only 8 bits are needed [checkme: tree-optimization SVN r165202])
re PR c++/44561 (using nullptr_t with -flto/-fwhopr causes ICE: tree code 'lang_type' is not supported in gimple streams [checkme: lto SVN r165462])
re PR c++/45382 (internal compiler error: tree code ‘call_expr’ is not supported in gimple streams [checkme: lto SVN r165471])
re PR tree-optimization/20165 (Pointer does not really escape with write [checkme: fortran SVN r165559])
re PR rtl-optimization/45834 (Redundant inter-loop edges in DDG [checkme: c SVN r165781])
re PR c++/46134 (constexpr vs. defaulted ctor [checkme: INVALID SVN r166171])
re PR debug/46241 (ice in dwarf2out.c [checkme: middle-end SVN r166245])
re PR tree-optimization/46183 (ICE: in calc_dfs_tree, at dominance.c:396 with -O -fno-dse -fgcse -ftree-pre [checkme: rtl-optimization SVN r166316])
re PR rtl-optimization/33172 (Optimizer fails to elid away unreferenced static function [checkme: tree-optimize SVN r166557])
re PR fortran/38669 (Array bounds violation for arguments of elemental subroutine [checkme: tree-optimize SVN r166579])
re PR rtl-optimization/42889 ("-fcompare-debug failure (length)" with "-O1 -fgcse" [checkme: debug SVN r166719])
re PR libgomp/45838 (FAIL: libgomp.c/pr34513.c execution test [checkme: middle-end SVN r166863])
re PR middle-end/46297 (gfortran.dg/g77/980701-0.f FAILs with -Os -fno-asynchronous-unwind-tables [checkme: middle-end-optimization SVN r166905])
re PR rtl-optimization/46665 (two gfortran tests fail with -O[2s] -fipa-pta -fno-tree-ccp -fno-tree-forwprop [checkme: tree-optimization SVN r167176])
re PR driver/44986 (-fuse-linker-plugin -save-temps gives resolution file base name of last argument [checkme: lto SVN r167292])
re PR c++/44871 (Invalid type mismatches while merging C and C++ sources [checkme: lto SVN r167367])
re PR middle-end/46745 ('#'mem_ref' not supported by dump_expr#<expression error>' [checkme: c SVN r167433])
re PR driver/46760 (LTO bootstrap doesn't work with FDO [checkme: tree-optimization SVN r167458])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r167487])
re PR lto/46576 (BFD linker plugin generates bad executables [checkme: debug SVN r167738])
re PR middle-end/46885 (ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:251 with -ftree-parallelize-loops -g [checkme: debug SVN r167801])
re PR tree-optimization/46469 (ICE: verify_cgraph_node failed: inline clone is needed at -O [checkme: tree-optmization SVN r168598])
re PR c/32511 (GCC rejects inline+weak function [checkme: middle-end SVN r168652])
re PR tree-optimization/46583 (-fcompare-debug failure with -O -fno-inline -fipa-cp -fipa-cp-clone [checkme: debug SVN r169058])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169310])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169377])
re PR fortran/47293 (libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing [checkme: libquadmath SVN r169466])
re PR c++/47541 (For integer pointers, the value of ++*p  is not written back to memory [checkme: tree-optimization SVN r169468])
re PR c++/47541 (For integer pointers, the value of ++*p  is not written back to memory [checkme: tree-optimization SVN r169472])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169634])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169677])
re PR fortran/47293 (libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing [checkme: libquadmath SVN r169738])
re PR c++/47541 (For integer pointers, the value of ++*p  is not written back to memory [checkme: tree-optimization SVN r169740])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r169851])
re PR debug/47647 (BLOCKs are empty [checkme: lto SVN r170321])
re PR debug/47283 (ICE in refs_may_alias_p_1, at tree-ssa-alias.c [checkme: middle-end SVN r170650])
re PR c++/48073 (ICE with -flto in templated C++ code [checkme: lto SVN r170875])
re PR c++/40866 (ICE in create_tmp_var, at gimplify.c:504 [checkme: libfortran SVN r170908])
re PR c++/40866 (ICE in create_tmp_var, at gimplify.c:504 [checkme: libfortran SVN r170912])
re PR rtl-optimization/48037 (Missed optimization: unnecessary register moves [checkme: tree-optimization SVN r170986])
re PR c++/13954 ([tree-ssa] SRA does not work for classes that use inheritance with an empty base [checkme: tree-optimization SVN r170994])
re PR driver/46944 (gcc should accept -fuse-linker-plugin only if linker handles -plugin [checkme: lto SVN r171039])
re PR c/48146 (ICE tree check: expected ssa_name, have var_decl in has_zero_uses, at tree-flow-inline.h:342 [checkme: tree-optimization SVN r171045])
re PR c/48650 (valgrind: Invalid write of size 8 in build_string (tree.c:1524) [checkme: middle-end SVN r172642])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172649])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172650])
re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172706])
re PR debug/48207 (ICE in lhd_set_decl_assembler_name, at langhooks.c:158 [checkme: lto SVN r172708])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172765])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172766])
re PR c/47892 (Fails to vectorize comparison code, if-conversion fails [checkme: tree-optimization SVN r172774])
re PR debug/48703 (segfault in canonicalize_for_substitution [checkme: lto SVN r172830])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172963])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172964])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173876])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173877])
re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r173901])
backport: re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r174476])
re PR java/23754 (tree check error in check_inner_circular_reference [checkme: lto SVN r175174])
re PR middle-end/49373 (Many testcase failures [checkme: tree-optimize SVN r175336])
re PR rtl-optimization/49169 (ARM: optimisations strip the Thumb/ARM mode bit off function pointers [checkme: tree-optimization SVN r175427])
re PR rtl-optimization/49686 (CFI notes are missed for delayed slot [checkme: debug SVN r176091])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176448])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176481])
re PR tree-optimization/49957 (Fails to SLP in 410.bwaves [checkme: fortran SVN r177368])
re PR middle-end/37221 (Missed early loop-unroll optimization - causes 40% degradation on SPU [checkme: fortran SVN r177486])
re PR debug/50006 (ICE in in connect_traces, at dwarf2cfi.c:2677 [checkme: middle-end SVN r177764])
re PR c++/40866 (ICE in create_tmp_var, at gimplify.c:504 [checkme: fortran SVN r178140])
re PR rtl-optimization/50191 (Strange debug insn produced for TOC compiling 416.gamess with profile-generate [checkme: debug SVN r178625])
re PR libgomp/50386 (libgomp.h:87:5: error: unnamed struct/union that defines no instances [checkme: middle-end SVN r179285])
re PR c/50507 (Huge amount of memory used while building GCC4 [checkme: c++ SVN r180002])
re PR middle-end/49310 (Compile time hog in var-tracking emit [checkme: debug SVN r180194])
re PR driver/41844 (lto1: warning: unknown register name: line-length-none [checkme: lto SVN r180517])
re PR rtl-optimization/50765 (ICE: in expand_insn, at optabs.c:7681 with -ftree-vectorize -fno-tree-dce [checkme: tree-optimization SVN r181617])
re PR debug/51262 (ICE: SIGSEGV in primary_template_instantiation_p (pt.c:2874) with -flto -g [checkme: lto SVN r182221])
re PR debug/48354 (internal compiler error: in splice_child_die, at dwarf2out.c:8064 [checkme: lto SVN r182286])
re PR debug/51564 (ICE in force_type_die, at dwarf2out.c:19288 [checkme: lto SVN r182367])
re PR debug/51567 (ICE in splice_child_die, at dwarf2out.c:5009 with -flto -g [checkme: lto SVN r182377])
re PR tree-optimization/51557 (ICE: in maybe_record_trace_start, at dwarf2cfi.c:2244 with custom flags [checkme: debug SVN r182404])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r182524])
re PR debug/51650 (LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul [checkme: lto SVN r182625])
re PR c/51730 (autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7 [checkme: middle-end SVN r182830])
re PR c/8081 (ICE with variably sized types returned from nested functions [checkme: middle-end SVN r183153])
re PR c++/53207 (bool conversion on return [checkme: tree-optimization SVN r184623])
re PR c++/52582 (g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit) [checkme: middle-end SVN r185381])
re PR c++/52772 (internal compiler error: Segmentation fault [checkme: middle-end SVN r186011])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186494])
re PR tree-optimization/44688 (Excessive code-size growth at -O3 [checkme: rtl-optimization SVN r186585])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186593])
re PR c++/53050 (ssa_forward_propagate_and_combine: segmentation fault [checkme: tree-optimization SVN r186620])
re PR c/11586 (after call sigaction, system() return wrong status [checkme: INVALID SVN r187542])
re PR rtl-optimization/53373 (ICE on valid code with -mavx [checkme: rtl-optimzation SVN r187695])
re PR fortran/53148 (Incorrect intrinsic function parsing on labeled statements when compiled w/ -ffrontend-optimize [checkme: c SVN r187718])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187931])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187932])
re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188298])
re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188386])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188387])
backport: re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188615])
backport: re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188625])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188811])
re PR rtl-optimization/53706 (Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418) [checkme: debug SVN r189037])
re PR c/53937 (Pack'ing struct causes gcc to not recognize that an field's address is aligned [checkme: middle-end SVN r189458])
re PR web/53919 (Version-specific install instructions not available [checkme: c++ SVN r189545])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190533])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190534])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r191066])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191614])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191615])
re PR middle-end/53024 (Support vector_size that is not a power of 2 [checkme: c SVN r191800])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192119])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192121])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192122])
re PR lto/54980 (gimple check: expected gimple_cond(error_mark), have gimple_call() in gimple_cond_set_lhs, at gimple.h:2578 [checkme: tree-optimize SVN r192809])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193331])
re PR rtl-optimization/55154 (ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags [checkme: tree-optimization SVN r193364])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193406])
re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r193649])
re PR tree-optimization/55052 (vect-widening tests are failing and giving wrong results [checkme: rtl-optimization SVN r193909])
re PR rtl-optimization/55717 (ICE in form_sum, at reload.c:5400 [checkme: debug SVN r194575])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r194680])
re PR tree-optimization/55875 (IVopts caused miscompilation [checkme: tree-optimiation SVN r195054])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r195173])
re PR libstdc++/51083 (TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained [checkme: tree-optimizatoin SVN r195274])
re PR rtl-optimization/55273 (ICE in iv_number_of_iterations, at loop-iv.c:2819 [checkme: tree-optimizatoin SVN r195275])
re PR libffi/56000 (FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test [checkme: middle-end SVN r195277])
re PR rtl-optimization/55270 (ICE in get_loop_body, at cfgloop.c:823 [checkme: tree-optimization SVN r195533])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195541])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195542])
re PR debug/54410 (doubled DW_TAG_template_type_param [checkme: c++ SVN r195613])
re PR sanitizer/55561 (TSAN: provide a TSAN instrumented libgomp [checkme: libgomp SVN r195618])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r195632])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195646])
backport: re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r195650])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195707])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195751])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195758])
re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r195796])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195844])
re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196133])
backport: re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r196141])
backport: re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196149])
re PR libstdc++/56557 (Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options [checkme: lto SVN r196613])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r196769])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197047])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197048])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197201])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197203])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197349])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197350])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197351])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197420])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197421])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197454])
re PR c++/56782 (Regression with empty pack expansions [checkme: fortran SVN r197610])
re PR c++/56782 (Regression with empty pack expansions [checkme: fortran SVN r197612])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198445])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198446])
re PR c++/57038 (Latest libreoffice compilation fails with enabled LTO [checkme: lto SVN r198917])
re PR tree-optimization/55177 (missed optimizations with __builtin_bswap [checkme: rtl-optimization SVN r199278])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199282])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199283])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199284])
re PR c++/57208 (Latest chromium compilation fails with enabled LTO [checkme: lto SVN r200468])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201696])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201697])
re PR c++/58201 (Undefined reference to `B::B(void const**)' [checkme: middle-end SVN r202298])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202496])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202498])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202564])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202565])
re PR c/20318 (RFE: add attribute to specify that a function never returns NULL [checkme: tree-optimization SVN r203316])
re PR c/52862 (ICE convert_to_pointer, at convert.c:50 [checkme: plugin SVN r204650])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205481])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205487])
backport: re PR target/59405 (Incorrect FP<->MMX transition during call/ret [checkme: INVALID SVN r205790])
re PR middle-end/59399 (ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow [checkme: sanitizer SVN r205888])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205991])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205993])
re PR fortran/45586 (ICE non-trivial conversion at assignment [checkme: lto SVN r206461])
re PR c++/58252 (ice in gimple_get_virt_method_for_binfo with -O2 [checkme: ipa SVN r206516])
re PR tree-optimization/46590 (long compile time with -O2 and many loops [checkme: rtl-optimization SVN r206663])
re PR fortran/59706 (ICE with do concurrent and internal subprogram [checkme: middle-end SVN r206732])
re PR ipa/59469 (LLVM build failure with gcc LTO [checkme: c++ SVN r207366])
re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r207695])
re PR fortran/60060 (lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096 [checkme: lto SVN r207715])
backport: re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r208366])
re PR c++/60474 (Crash in tree_class_check [checkme: middle-end SVN r208451])
re PR c++/60553 (segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO [checkme: middle-end SVN r208682])
re PR c++/60750 (double free after std::move on string inside throw when compiled with optimization [checkme: middle-end SVN r209179])
re PR libfortran/60706 (FAIL: gfortran.dg/size_kind_2.f90  -O   scan-tree-dump original "var2 = 42949673 00;" [checkme: middle-end SVN r209216])
re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209468])
backport: re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209630])
re PR debug/61070 (debug_bitmap writes to stdout [checkme: middle-end SVN r210098])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210181])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210203])
re PR c/61136 (ice in tree_nop_conversion [checkme: tree-optimization SVN r210312])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210426])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210472])
re PR c++/60189 (ICE with invalid use of _Cilk_sync [checkme: c SVN r210678])
re PR c++/60189 (ICE with invalid use of _Cilk_sync [checkme: c SVN r210680])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212174])
re PR middle-end/60226 (ICE initializing array of elements with too large alignment [checkme: c SVN r212346])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212436])
re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212521])
backport: re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212741])
re PR ipa/61921 (ICE: SIGSEGV in varpool_node::get_constructor(), at varpool.c:275 with -O2 -fipa-pta [checkme: tree-optimization SVN r213114])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r213308])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213491])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213492])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213812])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213901])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213904])
re PR tree-optimization/62079 (ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions [checkme: rtl-optimization SVN r213950])
re PR preprocessor/60975 (-Wvariadic-macros does not print warning [checkme: c SVN r214200])
re PR c++/62175 (Internal compiler error in gimplify_modify_expr gimplify.c:4616 [checkme: tree-optimization SVN r214492])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214543])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214546])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r214678])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r215134])
re PR c++/63419 (verify_gimple failed: "vector CONSTRUCTOR element is not a GIMPLE value" [checkme: tree-optimization SVN r216138])
re PR c++/62127 (ICE with VLA in constructor [checkme: tree-optimization SVN r216150])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r216273])
re PR c/63554 (ice in "execute_todo, at passes.c:1797" with -O3 [checkme: middle-end SVN r216315])
re PR middle-end/63879 (ICE compiling Linux Kernel fs/ext3/namei.c with -fsanitize=undefined [checkme: sanitizer SVN r217766])
re PR tree-optimization/64004 ([5 Regressio] Build error in tree-ssa-loop-niter.c in maybe_lower_iteration_bound [checkme: java SVN r218018])
re PR tree-optimization/64121 (ICE: SSA corruption with -O -fsanitize=undefined [checkme: sanitizer SVN r218222])
re PR web/64468 (Incorrect indentation in Doxygen-generated sources of libstdc++ [checkme: libstdc++ SVN r219147])
re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220152])
re PR sanitizer/64717 (-fsanitize=vptr leads to warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized] [checkme: c++ SVN r220262])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220327])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220335])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220420])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220617])
backport: re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220622])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220624])
re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r221776])
re PR c++/65626 (ICE in fixup_noreturn_call called by tree-ssa-forwprop.c:2492 [checkme: middle-end SVN r221790])
re PR middle-end/65554 (ICE: verify_gimple failed [checkme: c++ SVN r221808])
re PR c++/65851 (ice in set_lattice_value at tree-ssa-cc p.c:535 [checkme: tree-optimization SVN r222510])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222514])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222843])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222849])
re PR rtl-optimization/66187 (wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu [checkme: tree-optimization SVN r223366])
re PR ipa/65701 (r221530 makes 187.facerec drop with -Ofast -flto on bdver2 [checkme: tree-optimization SVN r223528])
backport: re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r224090])
re PR debug/66503 (missing DW_AT_abstract_origin for cross-unit call sites [checkme: middle-end SVN r224372])
re PR rtl-optimization/66351 (r223883 miscompiles stage2 compiler on ia64 [checkme: ipa SVN r224719])
re PR preprocessor/53690 ([C++11] \u0000 and \U00000000 are wrongly encoded as U+0001. [checkme: c++ SVN r225353])
re PR ipa/66793 (ICE at -Os and above on x86_64-linux-gnu (verify_flow_info failed) [checkme: tree-optimization SVN r225546])
re PR lto/66468 (ICE in in check_die, at dwarf2out.c:5719 [checkme: debug SVN r226255])
re PR debug/67043 (-fcompare-debug failure with -O3 [checkme: tree-optimization SVN r226540])
re PR c/67107 (ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations [checkme: middle-end SVN r226609])
re PR c/67279 (-fsanitize=undefined spurious error: initializer element is not constant [checkme: sanitizer SVN r227491])
re PR c/48885 (missed optimization with restrict qualifier? [checkme: tree-optimization SVN r228073])
re PR fortran/67170 (PRE can't hoist out a readonly argument [checkme: tree-optimization SVN r228244])
re PR c/67882 (surprising offsetof result on an invalid array member without diagnostic [checkme: c++-common SVN r229717])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230897])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230901])
re PR c++/67581 (ICE on transparent union with -g enabled on x86_64-linux-gnu (verify_type failed) [checkme: c SVN r231048])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231100])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231110])
re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231217])
re PR middle-end/68656 (warning about disabled var-tracking uses odd location info [checkme: c SVN r231292])
re PR debug/66688 (compare debug failure building Linux kernel on ppc64le [checkme: tree-optimization SVN r231644])
backport: re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231677])
re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r232122])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232169])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232171])
re PR tree-optimization/69164 (ICE in create_tmp_var, at gimple-expr.c:468 [checkme: c++ SVN r232187])
re PR debug/69077 (omnetpp ICEs with -flto -g [checkme: lto SVN r232272])
re PR c++/66487 (sanitizer/warnings for lifetime DSE [checkme: ipa SVN r232356])
re PR tree-optimization/69355 (Wrong results with -O1 optimization [checkme: c++ SVN r232663])
re PR c++/69267 ([cilkplus] ICE when calling a function with an empty class as an argument [checkme: cilkplus SVN r232887])
re PR middle-end/69643 (Address space discarded [checkme: c SVN r233189])
re PR middle-end/69537 (Incorrect -Wmaybe-uninitialized warning with enum variable [checkme: go SVN r233235])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233288])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233327])
re PR tree-optimization/69110 (execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2 [checkme: fortran SVN r233782])
re PR rtl-optimization/69052 (Performance regression after r229402. [checkme: tree-optimization SVN r233907])
re PR middle-end/70054 (GCC 6 gives a strict-aliasing warning on use of std::aligned_storage [checkme: c++ SVN r233961])
re PR sanitizer/70135 (-fsanitize=undefined causes static_assert to fail [checkme: c++ SVN r234064])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234248])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234249])
re PR libffi/70024 (libffi ABI change w/o SONAME bump [checkme: rtl-optimization SVN r234262])
re PR tree-optimization/70144 (g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref" [checkme: c++ SVN r234297])
re PR middle-end/70280 (-fcompare-debug failure (length) with --param=integer-share-limit=4016 -mavx512bw [checkme: c SVN r234312])
re PR middle-end/70273 (FAIL: g++.dg/ext/label13a.C  -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev [checkme: c++ SVN r234386])
re PR preprocessor/69650 (ICE in linemap_line_start, at libcpp/line-map.c:803 [checkme: lto SVN r234481])
re PR middle-end/70307 (ICE: in gimplify_expr, at gimplify.c:10915 on valid code [checkme: c SVN r234706])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235063])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235065])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235081])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235318])
re PR go/49889 (Calling a function whose name is obscured by a local variable does not produce an error [checkme: middle-end SVN r235484])
re PR fortran/70931 (ICE with -g in native_encode_initializer, bei dwarf2out.c:17768 [checkme: middle-end SVN r235944])
re PR ada/70786 (Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available) [checkme: tree-optimization SVN r236086])
re PR middle-end/71249 (-Wswitch-unreachable false positive for a compound statement containing a used label [checkme: c SVN r236649])
re PR c++/61564 (#pragma GCC optimize ("-fno-lto") causes the compiler to crash [checkme: c SVN r237174])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r237840])
re PR debug/71667 (ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize [checkme: tree-optimization SVN r238160])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r238238])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r238268])
re PR middle-end/50060 (intrinsics not folded by the middle-end [checkme: c++ SVN r238520])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238579])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238580])
re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239855])
re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239904])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239930])
backport: re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239933])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240006])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240025])
re PR rtl-optimization/64316 (ICE in simplify_const_unary_operation after r218503 [checkme: ipa SVN r240081])
re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r240348])
re PR fortran/77678 (ICE in fold_read_from_constant_string, at fold-const.c:13706 [checkme: middle-end SVN r240351])
re PR rtl-optimization/77714 (Wrong code generation for gcc.c-torture/execute/pr51447.c [checkme: rlt-optimization SVN r240518])
re PR c++/78051 (error: dead STMT in EH table when using -O2 [checkme: tree-optimization SVN r241394])
re PR c++/78826 (jump bypasses non-POD [checkme: fortran SVN r241909])
re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r241912])
re PR tree-optimization/35503 (Warning about restricted pointers? [checkme: c SVN r242366])
re PR tree-optimization/66419 (FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution,  -O3 -g [checkme: debug SVN r243126])
re PR tree-optimization/78692 (ICE (segfault) [checkme: c++ SVN r243377])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r243387])
backport: re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r243549])
backport: re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r243550])
re PR middle-end/78622 (-Wformat-length/-fprintf-return-value incorrect with overflow/wrapping [checkme: fortran SVN r243765])
re PR tree-optimization/78856 (wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes) [checkme: tree-optimizatin SVN r244045])
re PR tree-optimization/67955 (tree-dse does not use pointer info [checkme: tree-optimizatin SVN r244067])
re PR rtl-optimization/78812 (Wrong code generation due to hoisting memory load across function call [checkme: tree-optimizatin SVN r244093])
re PR middle-end/79089 (error: incorrect sharing of tree nodes [checkme: c SVN r244507])
re PR rtl-optimization/72488 (wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: tree-optimization SVN r244623])
re PR rtl-optimization/72488 (wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: tree-optimization SVN r244625])
backport: re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r244870])
re PR c++/79129 (ICE with -fdebug-types-section starting with r240578 [checkme: debug SVN r244955])
re PR rtl-optimization/71374 (ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190 [checkme: tree-optimization SVN r244991])
re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245053])
re PR tree-optimization/79347 (vect_do_peeling is messing up profile [checkme: tree-ssa SVN r245196])
re PR middle-end/56727 (Recursive call goes through the PLT unnecessarily [checkme: tree-ssa SVN r245359])
backport: re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245466])
re PR inline-asm/79552 (Wrong code generation due to -fschedule-insns, with __restrict__ and inline asm [checkme: tree-optimization SVN r245528])
re PR rtl-optimization/79286 (ira and lra wrong code at -O2 and -Os on i686-linux [checkme: rtl-optimizatoin SVN r245714])
re PR c/79731 (ICE: verify_gimple failed [checkme: middle-end SVN r245779])
re PR middle-end/79756 (ICE in execute_todo, at passes.c:2011 [checkme: c SVN r245838])
re PR fortran/79894 (ICE in gfc_add_modify_loc, at fortran/trans.c:159 [checkme: tree-optimization SVN r245923])
re PR c++/80075 (ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions [checkme: middle-end SVN r246223])
re PR middle-end/67338 (fold-const sanitizer runtime error  in roundup_loc [checkme: c SVN r246305])
re PR ipa/78644 (ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp [checkme: tree-optimization SVN r246534])
re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r246621])
re PR middle-end/80163 (ICE on hopefully valid code [checkme: c SVN r246876])
re PR c++/69953 (Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail [checkme: lto SVN r246899])
re PR debug/80453 (another compare-debug failure [checkme: tree-optimization SVN r247024])
re PR fortran/80494 (ICE in wide_int_to_tree [checkme: tree-optimization SVN r247095])
backport: re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r247694])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r248602])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r248612])
re PR sanitizer/81065 (UBSAN: false positive as a result of distribution involving different types [checkme: middle-end SVN r249144])
re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249174])
re PR sanitizer/81097 (UBSAN: false positive for not existing negation operator and a bogus message [checkme: middle-end SVN r249407])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249479])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249510])
re PR sanitizer/81505 (ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow [checkme: middle-end SVN r250494])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r250853])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r251143])
re PR c++/82054 (ICE in add_dwarf_attr with -fopenmp and -g [checkme: middle-end SVN r251559])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251661])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251711])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r252277])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r252458])
re PR debug/82144 (ICE in add_dwarf_attr with alignas [checkme: middle-end SVN r253134])
re PR c/82765 (ICE at -Os on valid code on x86_64-linux-gnu: in tree_to_shwi, at tree.c:6611 [checkme: middle-end SVN r254337])
re PR fortran/83017 (DO CONCURRENT not parallelizing [checkme: tree-optimization SVN r254867])
re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255354])
re PR tree-optimization/78496 (Missed opportunities for jump threading [checkme: tree-optimizatin SVN r255387])
re PR middle-end/83415 (ICE during gimplification of assignment to read-only vector [checkme: c SVN r255629])
re PR sanitizer/83388 (reference statement index not found error with -fsanitize=null [checkme: lto SVN r255694])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255722])
re PR ipa/81877 (Incorrect results with lto and -fipa-cp and -fipa-cp-clone [checkme: tree-optimization SVN r255776])
re PR c++/83482 (internal compiler error: Segmentation fault [checkme: tree-optimization SVN r255817])
re PR debug/83694 (New test case gcc.dg/pr83666.c from r256232 ICEs [checkme: middle-end SVN r256307])
re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256341])
re PR rtl-optimization/81308 (ICE in calc_dfs_tree, at dominance.c:458 [checkme: rtl-optimizatin SVN r256349])
re PR c++/80763 (-O3 causes error: inline clone in same comdat group list [checkme: ipa SVN r256369])
backport: re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256371])
re PR c++/86620 (__attribute__((no inline)) gives incorrect warning with overloaded functions [checkme: rtl-optimization SVN r256729])
re PR fortran/84000 (ICE in replace_loop_annotate, at tree-cfg.c:352 [checkme: middle-end SVN r257011])
re PR libgomp/84086 ([8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1 [checkme: tree-optimization SVN r257152])
re PR c++/84132 (tree-data-ref.c:3938: poor coding ? [checkme: tree-optimization SVN r257232])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257721])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257722])
re PR libgomp/84466 (libgomp.graphite/force-parallel-8.c fails starting with r257723 [checkme: tree-optimization SVN r258035])
re PR c/84607 (Side effects discarded in address computation inside 'if' [checkme: middle-end SVN r258061])
re PR middle-end/81812 (Empty virtual function fails to compile [checkme: c++ SVN r258150])
re PR middle-end/89497 (ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled [checkme: fortran SVN r258839])
re PR debug/85176 (ICE in force_decl_die, at dwarf2out.c:25910 [checkme: lto SVN r259080])
re PR rtl-optimization/85302 (ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu [checkme: debug SVN r259311])
re PR libstdc++/85116 (std::min_element does not optimize well with inlined predicate [checkme: tree-optimization SVN r259672])
re PR tree-optimization/85466 (Performance is slow when doing 'branchless' conditional style math operations [checkme: libstdc++ SVN r259921])
re PR c/86046 (ICE in execute_todo, at passes.c:2043 [checkme: tree-optimization SVN r261193])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r262042])
re PR debug/86523 (ICE in gen_member_die, at dwarf2out.c:24933 starting from r262560 [checkme: lto SVN r262696])
re PR debug/86456 (Segfault in switch_to_section at  gcc/varasm.c:7353 since r259317 [checkme: lto SVN r262819])
re PR lto/86654 (ICE in gen_member_die, at dwarf2out.c:24933 [checkme: debug SVN r262965])
re PR c++/78655 (gcc doesn't exploit the fact that the result of pointer addition can not be nullptr [checkme: tree-optimization SVN r263662])
re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r263967])
backport: re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r264107])
re PR middle-end/41453 (use INTENT(out) for optimization [checkme: fortran SVN r264506])
re PR c++/65667 (FAIL: g++.dg/cpp0x/pr57101.C  -std=gnu++11 (test for excess errors) [checkme: fortran SVN r264715])
re PR c/87682 (gcc/mem-stats.h:172: possible broken comparison operator ? [checkme: middle-end SVN r265376])
re PR c++/87469 (ice in record_estimate, at tree-ssa-loop-niter.c:3271 [checkme: middle-end SVN r265605])
re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r265776])
re PR c/87953 (asan: stack-buffer-overflow in vectorizable_reduction [checkme: tree-optimization SVN r265964])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266014])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266015])
re PR target/86677 (popcount builtin detection is breaking some kernel build [checkme: INVALID SVN r266039])
re PR c++/87229 (ICE: tree code 'call_expr' is not supported in LTO streams [checkme: lto SVN r266271])
re PR c++/87229 (ICE: tree code 'call_expr' is not supported in LTO streams [checkme: lto SVN r266372])
re PR sanitizer/88215 (UBSAN: Internal compiler error with attribute(unused) [checkme: c++ SVN r266546])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266550])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266553])
re PR tree-optimization/88367 (-fno-delete-null-pointer-checks doesn't work properly [checkme: c SVN r266878])
re PR c/87944 (Wrong code with LRA pushing stack local variable [checkme: fortran SVN r267184])
backport: re PR sanitizer/88215 (UBSAN: Internal compiler error with attribute(unused) [checkme: c++ SVN r267690])
re PR ipa/86590 (Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined [checkme: libstdc++ SVN r268112])
re PR tree-optimization/88606 (ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR) [checkme: c SVN r268540])
re PR libstdc++/87809 (Can't create empty std::optional<std::vector<int, CustomAlloc>> [checkme: lto SVN r268728])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268748])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268750])
re PR c++/89392 (ICE in bitmap_bit_p, at bitmap.c:978 [checkme: middle-end SVN r269065])
re PR lto/89514 (-g -fdebug-types-section -flto gives 'Dwarf Error: bad length' in gdb [checkme: debug SVN r269250])
re PR rtl-optimization/89487 (ICE in expand_expr_addr_expr_1, at expr.c:7993 [checkme: tree-optimization SVN r269361])
re PR rtl-optimization/89487 (ICE in expand_expr_addr_expr_1, at expr.c:7993 [checkme: tree-optimization SVN r269388])
re PR c++/89698 (Run-time error due to optimization of field access after cast at -Os/-O2 and higher [checkme: middle-end SVN r269677])
re PR libstdc++/87809 (Can't create empty std::optional<std::vector<int, CustomAlloc>> [checkme: lto SVN r269799])
re PR debug/89463 (debug information for iteractor of an empty loop is gone (at -O3) [checkme: tree-optimization SVN r269961])
re PR rtl-optimization/84101 (-O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure [checkme: tree-optimization SVN r270123])
re PR d/89004 (mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare] [checkme: fortran SVN r270150])
re PR c++/92001 (missing -Wclass-memaccess with array as first argument to memset [checkme: tree-optimization SVN r270499])
re PR debug/90194 (ICE in expand_debug_expr, at cfgexpand.c:5244 [checkme: middle-end SVN r270569])
re PR debug/90273 (GCC runs out of memory building Firefox [checkme: tree-optimization SVN r270674])
re PR debug/90273 (GCC runs out of memory building Firefox [checkme: tree-optimization SVN r270791])
re PR c++/89698 (Run-time error due to optimization of field access after cast at -Os/-O2 and higher [checkme: tree-optimization SVN r270833])
re PR preprocessor/90382 (ICE in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061 [checkme: c++ SVN r271032])
re PR tree-optimization/90474 (ICE: verify_gimple failed (error: DECL_GIMPLE_REG_P set on a variable with address taken; error: invalid address operand in MEM_REF) [checkme: c SVN r271206])
re PR debug/90716 (gcc generates wrong debug information at -O2 [checkme: tree-optimization SVN r271858])
re PR middle-end/90577 (FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto [checkme: fortran SVN r272309])
backport: re PR middle-end/90577 (FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto [checkme: fortran SVN r272437])
re PR rtl-optimization/91137 (Wrong code with -O3 [checkme: tree-optimization SVN r273570])
backport: re PR rtl-optimization/91137 (Wrong code with -O3 [checkme: tree-optimization SVN r273754])
re PR c++/91222 (507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571 [checkme: lto SVN r273866])
re PR c++/91445 (After memset, logical && operator produces false result, optimization level >=O1 [checkme: tree-optimization SVN r274533])
re PR c/91526 (Unnecessary SSE and other instructions generated when compiling in C mode (vs. C++ mode) [checkme: tree-optimization SVN r274922])
backport: re PR rtl-optimization/91137 (Wrong code with -O3 [checkme: tree-optimization SVN r275064])
backport: re PR rtl-optimization/91137 (Wrong code with -O3 [checkme: tree-optimization SVN r275304])
re PR lto/91772 (ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749 [checkme: debug SVN r275804])
re PR go/91763 (go.go-torture/execute/printnil.go FAILs [checkme: lto SVN r275872])
re PR c++/91222 (507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571 [checkme: lto SVN r276420])
re PR ipa/92133 (Support multi versioning on self recursive function [checkme: fortran SVN r277760])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277822])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277955])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277958])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r278289])

Re: Commit messages and the move to git

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1595 bytes --]

On Wed, 18 Dec 2019, Joseph Myers wrote:

> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> 
> > I've attached a sample from the start of the fixed list - the full list is far
> > too big to post to give a flavour of how the script currently works.  Note
> > that annotations of the form [checkme: ....] in the summary are for diagnostic
> > purposes.  These are where heuristics suggest that there's a higher than
> > normal chance that the PR number is incorrect and that manual auditing is
> > recommended.  Such annotations would not be appropriate in the final
> > conversion.
> 
> Concretely, here is the current list of 664 checkme: annotations where 
> something was suspicious about the PR number (either component mismatch or 
> resolved as INVALID).  Would some people like to volunteer to pick up 
> sections of this list and, for their section, produce a list of SVN 
> revisions (at the end of the checkme line) for which the PR number appears 
> to be correct, and a list of mappings from SVN revision to correct PR 
> number when the PR number appears to be wrong?  For any that don't get 
> reviewed like that we can easily make the script, for the final 
> conversion, decline to add a new summary line for any commit where the PR 
> number is suspicious.

Here's a slightly shorter version with 644 checkme: annotations, after 
adding a few more component aliases to the script (e.g., no longer 
considering it suspicious if the log message says PR g++/something and 
that PR is in the component that's actually called c++).

-- 
Joseph S. Myers
joseph@codesourcery.com

[-- Attachment #2: Type: text/plain, Size: 72237 bytes --]

re PR fortran/13911 ([g77]  Cannot initialize variables with declation as allowed by g77 [checkme: g++ SVN r17128])
re PR debug/5163 (Internal compiler error in add_abstract_origin_attribute, at dwarf2out.c:9296 [checkme: c SVN r48302])
re PR libffi/10610 ([powerpc-linux] 230 testsuite failures due to alignment errors [checkme: libgcj SVN r73019])
re PR libffi/10610 ([powerpc-linux] 230 testsuite failures due to alignment errors [checkme: libgcj SVN r73021])
re PR rtl-optimization/13024 (gcj can't build current rhug [checkme: java SVN r73752])
backport: re PR rtl-optimization/12816 (internal compiler error pari-2.1.5/Olinux-i686 [checkme: c++ SVN r75851])
revert: re PR tree-optimization/16115 (double-destruction problem with argument passing via temporary (breaks auto_ptr) [checkme: c++ SVN r84147])
re PR tree-optimization/15262 ([tree-ssa] Alias analyzer cannot handle addressable fields [checkme: c SVN r86398])
re PR rtl-optimization/15857 (Wrong code with optimization >= -O1 [checkme: c++ SVN r87429])
re PR c/16403 (Floating-point assignment to int is inconsistent [checkme: INVALID SVN r94142])
re PR c++/20505 (internal error when compiling with -ggdb2 and no error with -ggdb1 [checkme: debug SVN r97528])
re PR rtl-optimization/19210 (not using do-loop for some loops [checkme: tree-optimization SVN r102225])
re PR tree-optimization/21562 (Quiet bad codegen (unrolling + tail call interaction) [checkme: c SVN r103245])
re PR c/21419 (Accepts writting to const via asm [checkme: tree-optimization SVN r104991])
re PR awt/26641 (AWT mouse event handling regression [checkme: libgcj SVN r112464])
re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114637])
re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114639])
re PR middle-end/25505 (gcc uses way too much stack space for this code [checkme: c++ SVN r116634])
re PR libstdc++/39238 (trunk revision 144279 - cfenv:54: error: ‘::fenv_t’ has not been declared [checkme: fortran SVN r120056])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121666])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121667])
re PR debug/33739 (Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin [checkme: fortran SVN r130244])
re PR c++/31863 (g++-4.1: out of memory with -O1/-O2 [checkme: middle-end SVN r131405])
re PR c/34601 (ICE with undefined enum [checkme: middle-end SVN r131506])
re PR middle-end/34668 (ICE in find_compatible_field with -combine [checkme: c SVN r131572])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131649])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131670])
re PR tree-optimization/34885 (ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574 [checkme: c SVN r131694])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131719])
re PR c++/34953 (ICE on destructor + noreturn-function at -O3 [checkme: middle-end SVN r131782])
re PR translation/35002 (Incorrect spelling of "hottest" [checkme: c SVN r131940])
re PR driver/30330 (-Wdeprecated is not documented [checkme: documentation SVN r132131])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132382])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132493])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132494])
re PR tree-optimization/33512 (Simple bitwise simplification missed [checkme: rtl-opt SVN r132575])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132601])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132602])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132603])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r132821])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133106])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133108])
re PR classpath/35422 (no generated javadoc of java/util/concurrent from external/jsr166 [checkme: tree-opt SVN r133144])
re PR classpath/35422 (no generated javadoc of java/util/concurrent from external/jsr166 [checkme: tree-opt SVN r133163])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133195])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133220])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r133470])
re PR rtl-optimization/19580 (missed load/store motion [checkme: tree-optimization SVN r133683])
re PR preprocessor/34866 (valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c [checkme: libcpp SVN r134421])
re PR preprocessor/15500 (gcc ignores locale when converting wide string literals to wchar_t strings [checkme: libcpp SVN r134441])
re PR preprocessor/33415 (Can't compile .cpp file with UTF-8 BOM. [checkme: libcpp SVN r134507])
re PR c/36021 (__attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault [checkme: middle-end SVN r134595])
re PR c/36021 (__attribute__((alloc_size(n))) with function of no arguments causes gcc to segfault [checkme: middle-end SVN r134596])
re PR c++/35652 (offset warning should be given in the front-end [checkme: c SVN r134714])
re PR fortran/36117 (Use MPFR for bessel function (optimization, rejects valid F2008) [checkme: middle-end SVN r135113])
re PR c++/36185 (wrong code with  -O2 -fgcse-sm [checkme: rtl-optimization SVN r135159])
re PR c++/35336 (Broken diagnostic: 'bit_field_ref' not supported by dump_expr [checkme: middle-end SVN r136662])
re PR c++/36460 (No space between >'s not always handled in C++0x [checkme: c SVN r136919])
re PR middle-end/36571 (Default untyped return for AVR is byte register. [checkme: c SVN r136926])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r136989])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r137001])
re PR tree-optimization/34371 (verify_stmts failed (incorrect sharing of tree nodes) [checkme: fortran SVN r137088])
re PR rtl-optimization/36672 (IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829 [checkme: preprocessor SVN r137581])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r137793])
re PR c++/36852 (Two dimensional array in template method argument list incorrectly interpreted. [checkme: fortran SVN r138072])
re PR c++/36852 (Two dimensional array in template method argument list incorrectly interpreted. [checkme: libfortran SVN r138073])
re PR c++/36852 (Two dimensional array in template method argument list incorrectly interpreted. [checkme: fortran SVN r138170])
re PR c++/36852 (Two dimensional array in template method argument list incorrectly interpreted. [checkme: libfortran SVN r138172])
re PR ada/36957 (ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge [checkme: tree-optimization SVN r138217])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r138293])
re PR middle-end/36633 (warning "array subscript is below array bounds" on delete [] with -O2, -Wall [checkme: c++ SVN r138425])
re PR c++/17880 (-Wsequence-point doesn't warn inside if, while, do conditions, for beg/cond/end expressions etc. [checkme: c SVN r138904])
re PR c++/28152 (Diagnostic about wrong use _Complex prints __complex__ [checkme: c SVN r139097])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r139159])
re PR c++/8895 (ICE on invalid template default value specification [checkme: libgcj SVN r139492])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139784])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139786])
re PR ada/37328 (ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747 [checkme: tree-optimization SVN r139931])
re PR middle-end/18071 (-Winline does not respect -fno-default-inline [checkme: c++ SVN r140418])
re PR fortran/37588 (GENERIC type-bound procedure is not resolved [checkme: c++ SVN r140424])
re PR debug/37410 (DW_TAG_imported_module is not in its DW_TAG_lexical_block [checkme: c++ SVN r140895])
re PR middle-end/29609 (Even with  -O0 -g gcc optimizes a goto away and I cannot debug [checkme: debug SVN r140948])
re PR tree-optimization/37568 (ICE returning a struct [checkme: c++ SVN r141010])
re PR debug/27017 (Debug information for static local class members are not emitted [checkme: c++ SVN r141829])
re PR debug/27574 (MIssing debug info at -O0 for a local variable in a C++ constructor [checkme: c++ SVN r141984])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142840])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142841])
re PR middle-end/36191 (can't use complex in a eh region if non-call-exceptions is enabled [checkme: c++ SVN r142950])
re PR tree-optimization/35805 ([ira] error in start_allocno_priorities, at ira-color.c:1806 [checkme: rtl-optimization SVN r143027])
re PR tree-optimization/38385 (ICE with -O2 -ftree-loop-distribution [checkme: middlend SVN r143291])
re PR c++/38908 (Unexplained "'<anonymous>' is used uninitialized in this function" warning in cc1plus -m64 [checkme: middle-end SVN r143722])
re PR c++/29027 (template conversion specialization found by using declaration [checkme: c SVN r144443])
re PR c++/39409 (internal compiler error: Segmentation fault [checkme: libfortran SVN r144718])
re PR c++/29027 (template conversion specialization found by using declaration [checkme: c SVN r145422])
re PR c++/8781 (Pessimization of C++ (functional) code [checkme: tree-optimization SVN r145533])
re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145569])
backport: re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145574])
re PR middle-end/39614 (Internal error compiling CSiBE [checkme: c SVN r145737])
re PR rtl-optimization/37377 (Bootstrap failure compiling libgcc [checkme: fortran SVN r145965])
re PR c/39928 (gimplify_expr failure [checkme: middle-end SVN r146846])
re PR java/39940 (failure in jc1 on i686-apple-darwin9 host [checkme: tree-optimization SVN r147065])
re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r147659])
re PR middle-end/39834 (verify_cgraph_node failed with -O3 -Winline [checkme: debug SVN r148292])
re PR c++/40389 (optimizer bug (possibly) [checkme: tree-optimization SVN r148458])
re PR c++/40389 (optimizer bug (possibly) [checkme: middle-end SVN r148462])
backport: re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r148469])
re PR c++/40389 (optimizer bug (possibly) [checkme: tree-optimization SVN r148597])
re PR c++/40389 (optimizer bug (possibly) [checkme: middle-end SVN r148601])
re PR c++/40389 (optimizer bug (possibly) [checkme: middle-end SVN r148604])
re PR c++/40492 (ice in create_tmp_var [checkme: tree-optimization SVN r148787])
backport: re PR c++/40492 (ice in create_tmp_var [checkme: tree-optimization SVN r148797])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r149010])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149470])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149499])
re PR c/48388 (libgcc compilation causes a segfault [checkme: middle-end SVN r149516])
re PR middle-end/40867 (FAIL: StackTrace2 output - source compiled test [checkme: java SVN r150376])
re PR c++/41094 (Erroneous optimization of pow() with -ffast-math [checkme: middle-end SVN r150874])
re PR c++/41094 (Erroneous optimization of pow() with -ffast-math [checkme: middle-end SVN r151051])
re PR c++/41094 (Erroneous optimization of pow() with -ffast-math [checkme: middle-end SVN r151052])
re PR debug/40660 (Weird break points with 4.5, works with 4.4 [checkme: fortran SVN r151069])
re PR c/41163 (verify_gimple fails [checkme: middle-end SVN r151122])
re PR c++/41273 (ICE in add_virtual_operand, at tree-ssa-operands.c:638 [checkme: debug SVN r151454])
re PR c++/41144 (ice for legal code with -O2 in get_alias_set [checkme: middle-end SVN r151461])
re PR c/39779 (ICE shifting byte to the right with constant > 7FFFFFFF [checkme: rtl-optimization SVN r151573])
re PR c++/41275 (ICE: expand_expr_real_1, at expr.c:8416 [checkme: middle-end SVN r151631])
re PR c/41935 (ICE : tree check: expected integer_cst, have nop_expr in int_cst_value, at tree.c:8301 [checkme: middle-end SVN r153962])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154061])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154063])
re PR c++/26965 (Unnecessary debug info for unused consts in C++ [checkme: debug SVN r154157])
re PR c++/41961 (Internal error with -O3 and -ftree-parallelize-loops [checkme: tree-optimization SVN r154748])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154878])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154879])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154885])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154965])
re PR libstdc++/42381 (deque shouldn't reserve that much memory [checkme: libsdtc++ SVN r155271])
re PR tree-optimization/42386 (ICE in ipcp_iterate_stage, at ipa-cp.c:766 [checkme: c++ SVN r155321])
re PR rtl-optimization/42589 (bswap optimization does not work for 32bit (but for 64bit) on 64bit registers [checkme: tree-optimization SVN r155588])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r155765])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156010])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156016])
re PR tree-optimization/42685 ("-fcompare-debug failure" with "-O1 -funroll-loops" (2) [checkme: rtl-optimization SVN r156252])
re PR debug/42991 (cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s) [checkme: middle-end SVN r156575])
re PR c/43125 (Revision 156907 failed gcc.dg/attr-used.c [checkme: middle-end SVN r156927])
re PR rtl-optimization/40761 (IRA memory hog for insanely nested loops [checkme: tree-optimization SVN r157225])
re PR rtl-optimization/43058 (var-tracking uses up all virtual memory [checkme: debug SVN r157547])
re PR c/43661 (ice in fold_comparison, at fold-const.c:9579 [checkme: middle-end SVN r157984])
re PR tree-optimization/43611 (ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions [checkme: c++ SVN r158218])
re PR tree-optimization/43611 (ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions [checkme: c++ SVN r158376])
re PR debug/42425 (ICE declaring local class [checkme: lto SVN r158722])
re PR c++/43080 (ICE with anonymous union and -flto [checkme: lto SVN r158723])
re PR c++/40561 (code does not compile -- compiles fine when replacing != with !(==) [checkme: middle-end SVN r158778])
re PR middle-end/43880 (internal compiler error: in make_decl_rtl [checkme: c++ SVN r158824])
re PR middle-end/43880 (internal compiler error: in make_decl_rtl [checkme: c++ SVN r159069])
re PR c/44024 (missed optimization [checkme: middle-end SVN r159205])
re PR middle-end/44104 (New test failures [checkme: debug SVN r159367])
re PR c++/44256 (When using -flto and -fwhole-program the compiler/linker crash [checkme: lto SVN r159779])
re PR c++/41921 (Cross language don't work with typedef unnamed structs [checkme: lto SVN r160226])
re PR c++/41921 (Cross language don't work with typedef unnamed structs [checkme: lto SVN r160227])
re PR middle-end/44536 (OMP: missing error with default(none) [checkme: fortran SVN r160779])
re PR middle-end/44536 (OMP: missing error with default(none) [checkme: fortran SVN r160780])
re PR middle-end/44536 (OMP: missing error with default(none) [checkme: fortran SVN r160783])
re PR lto/44248 (-fcompare-debug failure with -flto/-fwhopr -g [checkme: debug SVN r161056])
backport: re PR middle-end/44104 (New test failures [checkme: debug SVN r161666])
re PR rtl-optimization/44479 (false dependencies are computed after vectorization [checkme: tree-optimization SVN r161802])
re PR c/44828 (possible integer wrong code bug [checkme: middle-end SVN r161869])
re PR c/44828 (possible integer wrong code bug [checkme: middle-end SVN r161942])
re PR c/44828 (possible integer wrong code bug [checkme: middle-end SVN r161956])
re PR fortran/44882 (Bogus types in references with mismatched commons [checkme: tree-optimization SVN r161990])
re PR debug/44689 (-fenable-icf-debug causes segfault in cp_function_decl_explicit_p [checkme: fortran SVN r162052])
re PR c++/36960 (Reference variable in virtually inherited base corrupted under optimization [checkme: tree-optimization SVN r162141])
re PR debug/44971 (-fcompare-debug failure with uninitialized read in walk_gimple_stmt [checkme: middle-end SVN r162329])
re PR c++/43850 (ice: tree code �template_type_parm� is not supported in gimple streams [checkme: lto SVN r162416])
re PR c/45176 (restrict qualifier is not used in a manually unrolled loop [checkme: middle-end SVN r162862])
re PR middle-end/45307 (Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated [checkme: c++ SVN r163380])
re PR middle-end/45307 (Stores expanding to no RTL not removed by tree optimizers, Empty ctors/dtors not eliminated [checkme: c++ SVN r163439])
re PR middle-end/45505 (gfortran.dg/pr25923.f90 [checkme: fortran SVN r163949])
re PR c++/45605 (Missed devirtualization [checkme: tree-optimization SVN r164148])
re PR c++/45605 (Missed devirtualization [checkme: tree-optimization SVN r164402])
re PR c++/45605 (Missed devirtualization [checkme: tree-optimize SVN r164438])
re PR libgomp/45838 (FAIL: libgomp.c/pr34513.c execution test [checkme: middle-end SVN r165012])
re PR c/45869 (type mismatch in shift expression produces ice with -O3 and -m32 [checkme: middle-end SVN r165108])
re PR c/45869 (type mismatch in shift expression produces ice with -O3 and -m32 [checkme: middle-end SVN r165113])
re PR rtl-optimization/45903 (unnecessary load of 32/64bit variable when only 8 bits are needed [checkme: tree-optimization SVN r165200])
re PR rtl-optimization/45903 (unnecessary load of 32/64bit variable when only 8 bits are needed [checkme: tree-optimization SVN r165202])
re PR c++/44561 (using nullptr_t with -flto/-fwhopr causes ICE: tree code 'lang_type' is not supported in gimple streams [checkme: lto SVN r165462])
re PR c++/45382 (internal compiler error: tree code ‘call_expr’ is not supported in gimple streams [checkme: lto SVN r165471])
re PR tree-optimization/20165 (Pointer does not really escape with write [checkme: fortran SVN r165559])
re PR rtl-optimization/45834 (Redundant inter-loop edges in DDG [checkme: c SVN r165781])
re PR c++/46134 (constexpr vs. defaulted ctor [checkme: INVALID SVN r166171])
re PR debug/46241 (ice in dwarf2out.c [checkme: middle-end SVN r166245])
re PR tree-optimization/46183 (ICE: in calc_dfs_tree, at dominance.c:396 with -O -fno-dse -fgcse -ftree-pre [checkme: rtl-optimization SVN r166316])
re PR rtl-optimization/33172 (Optimizer fails to elid away unreferenced static function [checkme: tree-optimize SVN r166557])
re PR fortran/38669 (Array bounds violation for arguments of elemental subroutine [checkme: tree-optimize SVN r166579])
re PR rtl-optimization/42889 ("-fcompare-debug failure (length)" with "-O1 -fgcse" [checkme: debug SVN r166719])
re PR libgomp/45838 (FAIL: libgomp.c/pr34513.c execution test [checkme: middle-end SVN r166863])
re PR middle-end/46297 (gfortran.dg/g77/980701-0.f FAILs with -Os -fno-asynchronous-unwind-tables [checkme: middle-end-optimization SVN r166905])
re PR rtl-optimization/46665 (two gfortran tests fail with -O[2s] -fipa-pta -fno-tree-ccp -fno-tree-forwprop [checkme: tree-optimization SVN r167176])
re PR driver/44986 (-fuse-linker-plugin -save-temps gives resolution file base name of last argument [checkme: lto SVN r167292])
re PR c++/44871 (Invalid type mismatches while merging C and C++ sources [checkme: lto SVN r167367])
re PR middle-end/46745 ('#'mem_ref' not supported by dump_expr#<expression error>' [checkme: c SVN r167433])
re PR driver/46760 (LTO bootstrap doesn't work with FDO [checkme: tree-optimization SVN r167458])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r167487])
re PR lto/46576 (BFD linker plugin generates bad executables [checkme: debug SVN r167738])
re PR middle-end/46885 (ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:251 with -ftree-parallelize-loops -g [checkme: debug SVN r167801])
re PR tree-optimization/46469 (ICE: verify_cgraph_node failed: inline clone is needed at -O [checkme: tree-optmization SVN r168598])
re PR c/32511 (GCC rejects inline+weak function [checkme: middle-end SVN r168652])
re PR tree-optimization/46583 (-fcompare-debug failure with -O -fno-inline -fipa-cp -fipa-cp-clone [checkme: debug SVN r169058])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169310])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169377])
re PR fortran/47293 (libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing [checkme: libquadmath SVN r169466])
re PR c++/47541 (For integer pointers, the value of ++*p  is not written back to memory [checkme: tree-optimization SVN r169468])
re PR c++/47541 (For integer pointers, the value of ++*p  is not written back to memory [checkme: tree-optimization SVN r169472])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169634])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169677])
re PR fortran/47293 (libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing [checkme: libquadmath SVN r169738])
re PR c++/47541 (For integer pointers, the value of ++*p  is not written back to memory [checkme: tree-optimization SVN r169740])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r169851])
re PR debug/47647 (BLOCKs are empty [checkme: lto SVN r170321])
re PR debug/47283 (ICE in refs_may_alias_p_1, at tree-ssa-alias.c [checkme: middle-end SVN r170650])
re PR c++/48073 (ICE with -flto in templated C++ code [checkme: lto SVN r170875])
re PR c++/40866 (ICE in create_tmp_var, at gimplify.c:504 [checkme: libfortran SVN r170908])
re PR c++/40866 (ICE in create_tmp_var, at gimplify.c:504 [checkme: libfortran SVN r170912])
re PR rtl-optimization/48037 (Missed optimization: unnecessary register moves [checkme: tree-optimization SVN r170986])
re PR c++/13954 ([tree-ssa] SRA does not work for classes that use inheritance with an empty base [checkme: tree-optimization SVN r170994])
re PR driver/46944 (gcc should accept -fuse-linker-plugin only if linker handles -plugin [checkme: lto SVN r171039])
re PR c/48146 (ICE tree check: expected ssa_name, have var_decl in has_zero_uses, at tree-flow-inline.h:342 [checkme: tree-optimization SVN r171045])
re PR c/48650 (valgrind: Invalid write of size 8 in build_string (tree.c:1524) [checkme: middle-end SVN r172642])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172649])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172650])
re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172706])
re PR debug/48207 (ICE in lhd_set_decl_assembler_name, at langhooks.c:158 [checkme: lto SVN r172708])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172765])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172766])
re PR c/47892 (Fails to vectorize comparison code, if-conversion fails [checkme: tree-optimization SVN r172774])
re PR debug/48703 (segfault in canonicalize_for_substitution [checkme: lto SVN r172830])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172963])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172964])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173876])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173877])
re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r173901])
backport: re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r174476])
re PR java/23754 (tree check error in check_inner_circular_reference [checkme: lto SVN r175174])
re PR middle-end/49373 (Many testcase failures [checkme: tree-optimize SVN r175336])
re PR rtl-optimization/49169 (ARM: optimisations strip the Thumb/ARM mode bit off function pointers [checkme: tree-optimization SVN r175427])
re PR rtl-optimization/49686 (CFI notes are missed for delayed slot [checkme: debug SVN r176091])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176448])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176481])
re PR tree-optimization/49957 (Fails to SLP in 410.bwaves [checkme: fortran SVN r177368])
re PR middle-end/37221 (Missed early loop-unroll optimization - causes 40% degradation on SPU [checkme: fortran SVN r177486])
re PR debug/50006 (ICE in in connect_traces, at dwarf2cfi.c:2677 [checkme: middle-end SVN r177764])
re PR c++/40866 (ICE in create_tmp_var, at gimplify.c:504 [checkme: fortran SVN r178140])
re PR rtl-optimization/50191 (Strange debug insn produced for TOC compiling 416.gamess with profile-generate [checkme: debug SVN r178625])
re PR libgomp/50386 (libgomp.h:87:5: error: unnamed struct/union that defines no instances [checkme: middle-end SVN r179285])
re PR c/50507 (Huge amount of memory used while building GCC4 [checkme: c++ SVN r180002])
re PR middle-end/49310 (Compile time hog in var-tracking emit [checkme: debug SVN r180194])
re PR driver/41844 (lto1: warning: unknown register name: line-length-none [checkme: lto SVN r180517])
re PR rtl-optimization/50765 (ICE: in expand_insn, at optabs.c:7681 with -ftree-vectorize -fno-tree-dce [checkme: tree-optimization SVN r181617])
re PR debug/51262 (ICE: SIGSEGV in primary_template_instantiation_p (pt.c:2874) with -flto -g [checkme: lto SVN r182221])
re PR debug/48354 (internal compiler error: in splice_child_die, at dwarf2out.c:8064 [checkme: lto SVN r182286])
re PR debug/51564 (ICE in force_type_die, at dwarf2out.c:19288 [checkme: lto SVN r182367])
re PR debug/51567 (ICE in splice_child_die, at dwarf2out.c:5009 with -flto -g [checkme: lto SVN r182377])
re PR tree-optimization/51557 (ICE: in maybe_record_trace_start, at dwarf2cfi.c:2244 with custom flags [checkme: debug SVN r182404])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r182524])
re PR debug/51650 (LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul [checkme: lto SVN r182625])
re PR c/51730 (autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7 [checkme: middle-end SVN r182830])
re PR c/8081 (ICE with variably sized types returned from nested functions [checkme: middle-end SVN r183153])
re PR c++/53207 (bool conversion on return [checkme: tree-optimization SVN r184623])
re PR c++/52582 (g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit) [checkme: middle-end SVN r185381])
re PR c++/52772 (internal compiler error: Segmentation fault [checkme: middle-end SVN r186011])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186494])
re PR tree-optimization/44688 (Excessive code-size growth at -O3 [checkme: rtl-optimization SVN r186585])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186593])
re PR c++/53050 (ssa_forward_propagate_and_combine: segmentation fault [checkme: tree-optimization SVN r186620])
re PR c/11586 (after call sigaction, system() return wrong status [checkme: INVALID SVN r187542])
re PR rtl-optimization/53373 (ICE on valid code with -mavx [checkme: rtl-optimzation SVN r187695])
re PR fortran/53148 (Incorrect intrinsic function parsing on labeled statements when compiled w/ -ffrontend-optimize [checkme: c SVN r187718])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187931])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187932])
re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188298])
re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188386])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188387])
backport: re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188615])
backport: re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188625])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188811])
re PR rtl-optimization/53706 (Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418) [checkme: debug SVN r189037])
re PR c/53937 (Pack'ing struct causes gcc to not recognize that an field's address is aligned [checkme: middle-end SVN r189458])
re PR web/53919 (Version-specific install instructions not available [checkme: c++ SVN r189545])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190533])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190534])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r191066])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191614])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191615])
re PR middle-end/53024 (Support vector_size that is not a power of 2 [checkme: c SVN r191800])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192119])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192121])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192122])
re PR lto/54980 (gimple check: expected gimple_cond(error_mark), have gimple_call() in gimple_cond_set_lhs, at gimple.h:2578 [checkme: tree-optimize SVN r192809])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193331])
re PR rtl-optimization/55154 (ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags [checkme: tree-optimization SVN r193364])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193406])
re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r193649])
re PR tree-optimization/55052 (vect-widening tests are failing and giving wrong results [checkme: rtl-optimization SVN r193909])
re PR rtl-optimization/55717 (ICE in form_sum, at reload.c:5400 [checkme: debug SVN r194575])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r194680])
re PR tree-optimization/55875 (IVopts caused miscompilation [checkme: tree-optimiation SVN r195054])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r195173])
re PR libstdc++/51083 (TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained [checkme: tree-optimizatoin SVN r195274])
re PR rtl-optimization/55273 (ICE in iv_number_of_iterations, at loop-iv.c:2819 [checkme: tree-optimizatoin SVN r195275])
re PR libffi/56000 (FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test [checkme: middle-end SVN r195277])
re PR rtl-optimization/55270 (ICE in get_loop_body, at cfgloop.c:823 [checkme: tree-optimization SVN r195533])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195541])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195542])
re PR debug/54410 (doubled DW_TAG_template_type_param [checkme: c++ SVN r195613])
re PR sanitizer/55561 (TSAN: provide a TSAN instrumented libgomp [checkme: libgomp SVN r195618])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r195632])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195646])
backport: re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r195650])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195707])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195751])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195758])
re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r195796])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195844])
re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196133])
backport: re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r196141])
backport: re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196149])
re PR libstdc++/56557 (Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options [checkme: lto SVN r196613])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r196769])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197047])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197048])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197201])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197203])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197349])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197350])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197351])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197420])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197421])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197454])
re PR c++/56782 (Regression with empty pack expansions [checkme: fortran SVN r197610])
re PR c++/56782 (Regression with empty pack expansions [checkme: fortran SVN r197612])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198445])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198446])
re PR c++/57038 (Latest libreoffice compilation fails with enabled LTO [checkme: lto SVN r198917])
re PR tree-optimization/55177 (missed optimizations with __builtin_bswap [checkme: rtl-optimization SVN r199278])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199282])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199283])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199284])
re PR c++/57208 (Latest chromium compilation fails with enabled LTO [checkme: lto SVN r200468])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201696])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201697])
re PR c++/58201 (Undefined reference to `B::B(void const**)' [checkme: middle-end SVN r202298])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202496])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202498])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202564])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202565])
re PR c/20318 (RFE: add attribute to specify that a function never returns NULL [checkme: tree-optimization SVN r203316])
re PR c/52862 (ICE convert_to_pointer, at convert.c:50 [checkme: plugin SVN r204650])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205481])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205487])
backport: re PR target/59405 (Incorrect FP<->MMX transition during call/ret [checkme: INVALID SVN r205790])
re PR middle-end/59399 (ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow [checkme: sanitizer SVN r205888])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205991])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205993])
re PR fortran/45586 (ICE non-trivial conversion at assignment [checkme: lto SVN r206461])
re PR c++/58252 (ice in gimple_get_virt_method_for_binfo with -O2 [checkme: ipa SVN r206516])
re PR tree-optimization/46590 (long compile time with -O2 and many loops [checkme: rtl-optimization SVN r206663])
re PR fortran/59706 (ICE with do concurrent and internal subprogram [checkme: middle-end SVN r206732])
re PR ipa/59469 (LLVM build failure with gcc LTO [checkme: c++ SVN r207366])
re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r207695])
re PR fortran/60060 (lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096 [checkme: lto SVN r207715])
backport: re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r208366])
re PR c++/60474 (Crash in tree_class_check [checkme: middle-end SVN r208451])
re PR c++/60553 (segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO [checkme: middle-end SVN r208682])
re PR c++/60750 (double free after std::move on string inside throw when compiled with optimization [checkme: middle-end SVN r209179])
re PR libfortran/60706 (FAIL: gfortran.dg/size_kind_2.f90  -O   scan-tree-dump original "var2 = 42949673 00;" [checkme: middle-end SVN r209216])
re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209468])
backport: re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209630])
re PR debug/61070 (debug_bitmap writes to stdout [checkme: middle-end SVN r210098])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210181])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210203])
re PR c/61136 (ice in tree_nop_conversion [checkme: tree-optimization SVN r210312])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210426])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210472])
re PR c++/60189 (ICE with invalid use of _Cilk_sync [checkme: c SVN r210678])
re PR c++/60189 (ICE with invalid use of _Cilk_sync [checkme: c SVN r210680])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212174])
re PR middle-end/60226 (ICE initializing array of elements with too large alignment [checkme: c SVN r212346])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212436])
re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212521])
backport: re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212741])
re PR ipa/61921 (ICE: SIGSEGV in varpool_node::get_constructor(), at varpool.c:275 with -O2 -fipa-pta [checkme: tree-optimization SVN r213114])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r213308])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213491])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213492])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213812])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213901])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213904])
re PR tree-optimization/62079 (ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions [checkme: rtl-optimization SVN r213950])
re PR preprocessor/60975 (-Wvariadic-macros does not print warning [checkme: c SVN r214200])
re PR c++/62175 (Internal compiler error in gimplify_modify_expr gimplify.c:4616 [checkme: tree-optimization SVN r214492])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214543])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214546])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r214678])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r215134])
re PR c++/63419 (verify_gimple failed: "vector CONSTRUCTOR element is not a GIMPLE value" [checkme: tree-optimization SVN r216138])
re PR c++/62127 (ICE with VLA in constructor [checkme: tree-optimization SVN r216150])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r216273])
re PR c/63554 (ice in "execute_todo, at passes.c:1797" with -O3 [checkme: middle-end SVN r216315])
re PR middle-end/63879 (ICE compiling Linux Kernel fs/ext3/namei.c with -fsanitize=undefined [checkme: sanitizer SVN r217766])
re PR tree-optimization/64004 ([5 Regressio] Build error in tree-ssa-loop-niter.c in maybe_lower_iteration_bound [checkme: java SVN r218018])
re PR tree-optimization/64121 (ICE: SSA corruption with -O -fsanitize=undefined [checkme: sanitizer SVN r218222])
re PR web/64468 (Incorrect indentation in Doxygen-generated sources of libstdc++ [checkme: libstdc++ SVN r219147])
re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220152])
re PR sanitizer/64717 (-fsanitize=vptr leads to warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized] [checkme: c++ SVN r220262])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220327])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220335])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220420])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220617])
backport: re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220622])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220624])
re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r221776])
re PR c++/65626 (ICE in fixup_noreturn_call called by tree-ssa-forwprop.c:2492 [checkme: middle-end SVN r221790])
re PR middle-end/65554 (ICE: verify_gimple failed [checkme: c++ SVN r221808])
re PR c++/65851 (ice in set_lattice_value at tree-ssa-cc p.c:535 [checkme: tree-optimization SVN r222510])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222514])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222843])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222849])
re PR rtl-optimization/66187 (wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu [checkme: tree-optimization SVN r223366])
re PR ipa/65701 (r221530 makes 187.facerec drop with -Ofast -flto on bdver2 [checkme: tree-optimization SVN r223528])
backport: re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r224090])
re PR debug/66503 (missing DW_AT_abstract_origin for cross-unit call sites [checkme: middle-end SVN r224372])
re PR rtl-optimization/66351 (r223883 miscompiles stage2 compiler on ia64 [checkme: ipa SVN r224719])
re PR preprocessor/53690 ([C++11] \u0000 and \U00000000 are wrongly encoded as U+0001. [checkme: c++ SVN r225353])
re PR ipa/66793 (ICE at -Os and above on x86_64-linux-gnu (verify_flow_info failed) [checkme: tree-optimization SVN r225546])
re PR lto/66468 (ICE in in check_die, at dwarf2out.c:5719 [checkme: debug SVN r226255])
re PR debug/67043 (-fcompare-debug failure with -O3 [checkme: tree-optimization SVN r226540])
re PR c/67107 (ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations [checkme: middle-end SVN r226609])
re PR c/67279 (-fsanitize=undefined spurious error: initializer element is not constant [checkme: sanitizer SVN r227491])
re PR c/48885 (missed optimization with restrict qualifier? [checkme: tree-optimization SVN r228073])
re PR fortran/67170 (PRE can't hoist out a readonly argument [checkme: tree-optimization SVN r228244])
re PR c/67882 (surprising offsetof result on an invalid array member without diagnostic [checkme: c++-common SVN r229717])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230897])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230901])
re PR c++/67581 (ICE on transparent union with -g enabled on x86_64-linux-gnu (verify_type failed) [checkme: c SVN r231048])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231100])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231110])
re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231217])
re PR middle-end/68656 (warning about disabled var-tracking uses odd location info [checkme: c SVN r231292])
re PR debug/66688 (compare debug failure building Linux kernel on ppc64le [checkme: tree-optimization SVN r231644])
backport: re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231677])
re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r232122])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232169])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232171])
re PR tree-optimization/69164 (ICE in create_tmp_var, at gimple-expr.c:468 [checkme: c++ SVN r232187])
re PR debug/69077 (omnetpp ICEs with -flto -g [checkme: lto SVN r232272])
re PR c++/66487 (sanitizer/warnings for lifetime DSE [checkme: ipa SVN r232356])
re PR tree-optimization/69355 (Wrong results with -O1 optimization [checkme: c++ SVN r232663])
re PR c++/69267 ([cilkplus] ICE when calling a function with an empty class as an argument [checkme: cilkplus SVN r232887])
re PR middle-end/69643 (Address space discarded [checkme: c SVN r233189])
re PR middle-end/69537 (Incorrect -Wmaybe-uninitialized warning with enum variable [checkme: go SVN r233235])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233288])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233327])
re PR tree-optimization/69110 (execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2 [checkme: fortran SVN r233782])
re PR rtl-optimization/69052 (Performance regression after r229402. [checkme: tree-optimization SVN r233907])
re PR middle-end/70054 (GCC 6 gives a strict-aliasing warning on use of std::aligned_storage [checkme: c++ SVN r233961])
re PR sanitizer/70135 (-fsanitize=undefined causes static_assert to fail [checkme: c++ SVN r234064])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234248])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234249])
re PR libffi/70024 (libffi ABI change w/o SONAME bump [checkme: rtl-optimization SVN r234262])
re PR tree-optimization/70144 (g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref" [checkme: c++ SVN r234297])
re PR middle-end/70280 (-fcompare-debug failure (length) with --param=integer-share-limit=4016 -mavx512bw [checkme: c SVN r234312])
re PR middle-end/70273 (FAIL: g++.dg/ext/label13a.C  -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev [checkme: c++ SVN r234386])
re PR preprocessor/69650 (ICE in linemap_line_start, at libcpp/line-map.c:803 [checkme: lto SVN r234481])
re PR middle-end/70307 (ICE: in gimplify_expr, at gimplify.c:10915 on valid code [checkme: c SVN r234706])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235063])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235065])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235081])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235318])
re PR go/49889 (Calling a function whose name is obscured by a local variable does not produce an error [checkme: middle-end SVN r235484])
re PR fortran/70931 (ICE with -g in native_encode_initializer, bei dwarf2out.c:17768 [checkme: middle-end SVN r235944])
re PR ada/70786 (Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available) [checkme: tree-optimization SVN r236086])
re PR middle-end/71249 (-Wswitch-unreachable false positive for a compound statement containing a used label [checkme: c SVN r236649])
re PR c++/61564 (#pragma GCC optimize ("-fno-lto") causes the compiler to crash [checkme: c SVN r237174])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r237840])
re PR debug/71667 (ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize [checkme: tree-optimization SVN r238160])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r238238])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r238268])
re PR middle-end/50060 (intrinsics not folded by the middle-end [checkme: c++ SVN r238520])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238579])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238580])
re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239855])
re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239904])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239930])
backport: re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239933])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240006])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240025])
re PR rtl-optimization/64316 (ICE in simplify_const_unary_operation after r218503 [checkme: ipa SVN r240081])
re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r240348])
re PR fortran/77678 (ICE in fold_read_from_constant_string, at fold-const.c:13706 [checkme: middle-end SVN r240351])
re PR rtl-optimization/77714 (Wrong code generation for gcc.c-torture/execute/pr51447.c [checkme: rlt-optimization SVN r240518])
re PR c++/78051 (error: dead STMT in EH table when using -O2 [checkme: tree-optimization SVN r241394])
re PR c++/78826 (jump bypasses non-POD [checkme: fortran SVN r241909])
re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r241912])
re PR tree-optimization/35503 (Warning about restricted pointers? [checkme: c SVN r242366])
re PR tree-optimization/66419 (FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution,  -O3 -g [checkme: debug SVN r243126])
re PR tree-optimization/78692 (ICE (segfault) [checkme: c++ SVN r243377])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r243387])
backport: re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r243549])
backport: re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r243550])
re PR middle-end/78622 (-Wformat-length/-fprintf-return-value incorrect with overflow/wrapping [checkme: fortran SVN r243765])
re PR tree-optimization/78856 (wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes) [checkme: tree-optimizatin SVN r244045])
re PR tree-optimization/67955 (tree-dse does not use pointer info [checkme: tree-optimizatin SVN r244067])
re PR rtl-optimization/78812 (Wrong code generation due to hoisting memory load across function call [checkme: tree-optimizatin SVN r244093])
re PR middle-end/79089 (error: incorrect sharing of tree nodes [checkme: c SVN r244507])
re PR rtl-optimization/72488 (wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: tree-optimization SVN r244623])
re PR rtl-optimization/72488 (wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: tree-optimization SVN r244625])
backport: re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r244870])
re PR c++/79129 (ICE with -fdebug-types-section starting with r240578 [checkme: debug SVN r244955])
re PR rtl-optimization/71374 (ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190 [checkme: tree-optimization SVN r244991])
re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245053])
re PR tree-optimization/79347 (vect_do_peeling is messing up profile [checkme: tree-ssa SVN r245196])
re PR middle-end/56727 (Recursive call goes through the PLT unnecessarily [checkme: tree-ssa SVN r245359])
backport: re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245466])
re PR inline-asm/79552 (Wrong code generation due to -fschedule-insns, with __restrict__ and inline asm [checkme: tree-optimization SVN r245528])
re PR rtl-optimization/79286 (ira and lra wrong code at -O2 and -Os on i686-linux [checkme: rtl-optimizatoin SVN r245714])
re PR c/79731 (ICE: verify_gimple failed [checkme: middle-end SVN r245779])
re PR middle-end/79756 (ICE in execute_todo, at passes.c:2011 [checkme: c SVN r245838])
re PR fortran/79894 (ICE in gfc_add_modify_loc, at fortran/trans.c:159 [checkme: tree-optimization SVN r245923])
re PR c++/80075 (ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions [checkme: middle-end SVN r246223])
re PR middle-end/67338 (fold-const sanitizer runtime error  in roundup_loc [checkme: c SVN r246305])
re PR ipa/78644 (ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp [checkme: tree-optimization SVN r246534])
re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r246621])
re PR middle-end/80163 (ICE on hopefully valid code [checkme: c SVN r246876])
re PR c++/69953 (Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail [checkme: lto SVN r246899])
re PR debug/80453 (another compare-debug failure [checkme: tree-optimization SVN r247024])
re PR fortran/80494 (ICE in wide_int_to_tree [checkme: tree-optimization SVN r247095])
backport: re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r247694])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r248602])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r248612])
re PR sanitizer/81065 (UBSAN: false positive as a result of distribution involving different types [checkme: middle-end SVN r249144])
re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249174])
re PR sanitizer/81097 (UBSAN: false positive for not existing negation operator and a bogus message [checkme: middle-end SVN r249407])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249479])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249510])
re PR sanitizer/81505 (ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow [checkme: middle-end SVN r250494])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r250853])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r251143])
re PR c++/82054 (ICE in add_dwarf_attr with -fopenmp and -g [checkme: middle-end SVN r251559])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251661])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251711])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r252277])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r252458])
re PR debug/82144 (ICE in add_dwarf_attr with alignas [checkme: middle-end SVN r253134])
re PR c/82765 (ICE at -Os on valid code on x86_64-linux-gnu: in tree_to_shwi, at tree.c:6611 [checkme: middle-end SVN r254337])
re PR fortran/83017 (DO CONCURRENT not parallelizing [checkme: tree-optimization SVN r254867])
re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255354])
re PR tree-optimization/78496 (Missed opportunities for jump threading [checkme: tree-optimizatin SVN r255387])
re PR middle-end/83415 (ICE during gimplification of assignment to read-only vector [checkme: c SVN r255629])
re PR sanitizer/83388 (reference statement index not found error with -fsanitize=null [checkme: lto SVN r255694])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255722])
re PR ipa/81877 (Incorrect results with lto and -fipa-cp and -fipa-cp-clone [checkme: tree-optimization SVN r255776])
re PR c++/83482 (internal compiler error: Segmentation fault [checkme: tree-optimization SVN r255817])
re PR debug/83694 (New test case gcc.dg/pr83666.c from r256232 ICEs [checkme: middle-end SVN r256307])
re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256341])
re PR rtl-optimization/81308 (ICE in calc_dfs_tree, at dominance.c:458 [checkme: rtl-optimizatin SVN r256349])
re PR c++/80763 (-O3 causes error: inline clone in same comdat group list [checkme: ipa SVN r256369])
backport: re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256371])
re PR c++/86620 (__attribute__((no inline)) gives incorrect warning with overloaded functions [checkme: rtl-optimization SVN r256729])
re PR fortran/84000 (ICE in replace_loop_annotate, at tree-cfg.c:352 [checkme: middle-end SVN r257011])
re PR libgomp/84086 ([8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1 [checkme: tree-optimization SVN r257152])
re PR c++/84132 (tree-data-ref.c:3938: poor coding ? [checkme: tree-optimization SVN r257232])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257721])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257722])
re PR libgomp/84466 (libgomp.graphite/force-parallel-8.c fails starting with r257723 [checkme: tree-optimization SVN r258035])
re PR c/84607 (Side effects discarded in address computation inside 'if' [checkme: middle-end SVN r258061])
re PR middle-end/81812 (Empty virtual function fails to compile [checkme: c++ SVN r258150])
re PR middle-end/89497 (ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled [checkme: fortran SVN r258839])
re PR debug/85176 (ICE in force_decl_die, at dwarf2out.c:25910 [checkme: lto SVN r259080])
re PR rtl-optimization/85302 (ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu [checkme: debug SVN r259311])
re PR libstdc++/85116 (std::min_element does not optimize well with inlined predicate [checkme: tree-optimization SVN r259672])
re PR tree-optimization/85466 (Performance is slow when doing 'branchless' conditional style math operations [checkme: libstdc++ SVN r259921])
re PR c/86046 (ICE in execute_todo, at passes.c:2043 [checkme: tree-optimization SVN r261193])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r262042])
re PR debug/86523 (ICE in gen_member_die, at dwarf2out.c:24933 starting from r262560 [checkme: lto SVN r262696])
re PR debug/86456 (Segfault in switch_to_section at  gcc/varasm.c:7353 since r259317 [checkme: lto SVN r262819])
re PR lto/86654 (ICE in gen_member_die, at dwarf2out.c:24933 [checkme: debug SVN r262965])
re PR c++/78655 (gcc doesn't exploit the fact that the result of pointer addition can not be nullptr [checkme: tree-optimization SVN r263662])
re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r263967])
backport: re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r264107])
re PR middle-end/41453 (use INTENT(out) for optimization [checkme: fortran SVN r264506])
re PR c++/65667 (FAIL: g++.dg/cpp0x/pr57101.C  -std=gnu++11 (test for excess errors) [checkme: fortran SVN r264715])
re PR c/87682 (gcc/mem-stats.h:172: possible broken comparison operator ? [checkme: middle-end SVN r265376])
re PR c++/87469 (ice in record_estimate, at tree-ssa-loop-niter.c:3271 [checkme: middle-end SVN r265605])
re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r265776])
re PR c/87953 (asan: stack-buffer-overflow in vectorizable_reduction [checkme: tree-optimization SVN r265964])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266014])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266015])
re PR target/86677 (popcount builtin detection is breaking some kernel build [checkme: INVALID SVN r266039])
re PR c++/87229 (ICE: tree code 'call_expr' is not supported in LTO streams [checkme: lto SVN r266271])
re PR c++/87229 (ICE: tree code 'call_expr' is not supported in LTO streams [checkme: lto SVN r266372])
re PR sanitizer/88215 (UBSAN: Internal compiler error with attribute(unused) [checkme: c++ SVN r266546])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266550])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266553])
re PR tree-optimization/88367 (-fno-delete-null-pointer-checks doesn't work properly [checkme: c SVN r266878])
re PR c/87944 (Wrong code with LRA pushing stack local variable [checkme: fortran SVN r267184])
backport: re PR sanitizer/88215 (UBSAN: Internal compiler error with attribute(unused) [checkme: c++ SVN r267690])
re PR ipa/86590 (Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined [checkme: libstdc++ SVN r268112])
re PR tree-optimization/88606 (ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR) [checkme: c SVN r268540])
re PR libstdc++/87809 (Can't create empty std::optional<std::vector<int, CustomAlloc>> [checkme: lto SVN r268728])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268748])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268750])
re PR c++/89392 (ICE in bitmap_bit_p, at bitmap.c:978 [checkme: middle-end SVN r269065])
re PR lto/89514 (-g -fdebug-types-section -flto gives 'Dwarf Error: bad length' in gdb [checkme: debug SVN r269250])
re PR rtl-optimization/89487 (ICE in expand_expr_addr_expr_1, at expr.c:7993 [checkme: tree-optimization SVN r269361])
re PR rtl-optimization/89487 (ICE in expand_expr_addr_expr_1, at expr.c:7993 [checkme: tree-optimization SVN r269388])
re PR c++/89698 (Run-time error due to optimization of field access after cast at -Os/-O2 and higher [checkme: middle-end SVN r269677])
re PR libstdc++/87809 (Can't create empty std::optional<std::vector<int, CustomAlloc>> [checkme: lto SVN r269799])
re PR debug/89463 (debug information for iteractor of an empty loop is gone (at -O3) [checkme: tree-optimization SVN r269961])
re PR rtl-optimization/84101 (-O3 and -ftree-vectorize trying too hard for function returning trivial pair-of-uint64_t-structure [checkme: tree-optimization SVN r270123])
re PR d/89004 (mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare] [checkme: fortran SVN r270150])
re PR c++/92001 (missing -Wclass-memaccess with array as first argument to memset [checkme: tree-optimization SVN r270499])
re PR debug/90194 (ICE in expand_debug_expr, at cfgexpand.c:5244 [checkme: middle-end SVN r270569])
re PR debug/90273 (GCC runs out of memory building Firefox [checkme: tree-optimization SVN r270674])
re PR debug/90273 (GCC runs out of memory building Firefox [checkme: tree-optimization SVN r270791])
re PR c++/89698 (Run-time error due to optimization of field access after cast at -Os/-O2 and higher [checkme: tree-optimization SVN r270833])
re PR preprocessor/90382 (ICE in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061 [checkme: c++ SVN r271032])
re PR tree-optimization/90474 (ICE: verify_gimple failed (error: DECL_GIMPLE_REG_P set on a variable with address taken; error: invalid address operand in MEM_REF) [checkme: c SVN r271206])
re PR debug/90716 (gcc generates wrong debug information at -O2 [checkme: tree-optimization SVN r271858])
re PR middle-end/90577 (FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto [checkme: fortran SVN r272309])
backport: re PR middle-end/90577 (FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto [checkme: fortran SVN r272437])
re PR rtl-optimization/91137 (Wrong code with -O3 [checkme: tree-optimization SVN r273570])
backport: re PR rtl-optimization/91137 (Wrong code with -O3 [checkme: tree-optimization SVN r273754])
re PR c++/91222 (507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571 [checkme: lto SVN r273866])
re PR c++/91445 (After memset, logical && operator produces false result, optimization level >=O1 [checkme: tree-optimization SVN r274533])
re PR c/91526 (Unnecessary SSE and other instructions generated when compiling in C mode (vs. C++ mode) [checkme: tree-optimization SVN r274922])
backport: re PR rtl-optimization/91137 (Wrong code with -O3 [checkme: tree-optimization SVN r275064])
backport: re PR rtl-optimization/91137 (Wrong code with -O3 [checkme: tree-optimization SVN r275304])
re PR lto/91772 (ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749 [checkme: debug SVN r275804])
re PR go/91763 (go.go-torture/execute/printnil.go FAILs [checkme: lto SVN r275872])
re PR c++/91222 (507.cactuBSSN_r build fails in warn_types_mismatch at ipa-devirt.c:1006 since r273571 [checkme: lto SVN r276420])
re PR ipa/92133 (Support multi versioning on self recursive function [checkme: fortran SVN r277760])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277822])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277955])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277958])
re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r278289])

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Wed, 18 Dec 2019, Joseph Myers wrote:
>
> > On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> >
> > > I've attached a sample from the start of the fixed list - the full list is far
> > > too big to post to give a flavour of how the script currently works.  Note
> > > that annotations of the form [checkme: ....] in the summary are for diagnostic
> > > purposes.  These are where heuristics suggest that there's a higher than
> > > normal chance that the PR number is incorrect and that manual auditing is
> > > recommended.  Such annotations would not be appropriate in the final
> > > conversion.
> >
> > Concretely, here is the current list of 664 checkme: annotations where
> > something was suspicious about the PR number (either component mismatch or
> > resolved as INVALID).  Would some people like to volunteer to pick up
> > sections of this list and, for their section, produce a list of SVN
> > revisions (at the end of the checkme line) for which the PR number appears
> > to be correct, and a list of mappings from SVN revision to correct PR
> > number when the PR number appears to be wrong?  For any that don't get
> > reviewed like that we can easily make the script, for the final
> > conversion, decline to add a new summary line for any commit where the PR
> > number is suspicious.
>
> Here's a slightly shorter version with 644 checkme: annotations, after
> adding a few more component aliases to the script (e.g., no longer
> considering it suspicious if the log message says PR g++/something and
> that PR is in the component that's actually called c++).

Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
Line 326: lto SVN r196613, PR number is correct
Line 411: libstdc++ SVN r219147, PR number is correct


How do you want the mapping from SVN revision to correct PR to be expressed?

Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 39238)
Line 608: lto SVN r268728 should be PR 87089 (not 87809)
Line 616: lto SVN r269799 should be PR 87089 (not 87809)

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 09:27, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Wed, 18 Dec 2019, Joseph Myers wrote:
> >
> > > On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> > >
> > > > I've attached a sample from the start of the fixed list - the full list is far
> > > > too big to post to give a flavour of how the script currently works.  Note
> > > > that annotations of the form [checkme: ....] in the summary are for diagnostic
> > > > purposes.  These are where heuristics suggest that there's a higher than
> > > > normal chance that the PR number is incorrect and that manual auditing is
> > > > recommended.  Such annotations would not be appropriate in the final
> > > > conversion.
> > >
> > > Concretely, here is the current list of 664 checkme: annotations where
> > > something was suspicious about the PR number (either component mismatch or
> > > resolved as INVALID).  Would some people like to volunteer to pick up
> > > sections of this list and, for their section, produce a list of SVN
> > > revisions (at the end of the checkme line) for which the PR number appears
> > > to be correct, and a list of mappings from SVN revision to correct PR
> > > number when the PR number appears to be wrong?  For any that don't get
> > > reviewed like that we can easily make the script, for the final
> > > conversion, decline to add a new summary line for any commit where the PR
> > > number is suspicious.
> >
> > Here's a slightly shorter version with 644 checkme: annotations, after
> > adding a few more component aliases to the script (e.g., no longer
> > considering it suspicious if the log message says PR g++/something and
> > that PR is in the component that's actually called c++).
>
> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
> Line 326: lto SVN r196613, PR number is correct
> Line 411: libstdc++ SVN r219147, PR number is correct
>
>
> How do you want the mapping from SVN revision to correct PR to be expressed?
>
> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 39238)
> Line 608: lto SVN r268728 should be PR 87089 (not 87809)
> Line 616: lto SVN r269799 should be PR 87089 (not 87809)

I can take a chunk of the file, but I'll wait until I know how to
present the results.

Re: Commit messages and the move to git

[Jakub Jelinek]

On Thu, Dec 19, 2019 at 12:01:28AM +0000, Joseph Myers wrote:
> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277822])
> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277955])
> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277958])
> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r278289])

These are correct PR numbers, guess easiest check would be change c ->
tree_optimization in the bugzilla to match what the bug really was.

	Jakub

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/12/2019 09:27, Jonathan Wakely wrote:
> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> wrote:
>>
>> On Wed, 18 Dec 2019, Joseph Myers wrote:
>>
>>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
>>>
>>>> I've attached a sample from the start of the fixed list - the full list is far
>>>> too big to post to give a flavour of how the script currently works.  Note
>>>> that annotations of the form [checkme: ....] in the summary are for diagnostic
>>>> purposes.  These are where heuristics suggest that there's a higher than
>>>> normal chance that the PR number is incorrect and that manual auditing is
>>>> recommended.  Such annotations would not be appropriate in the final
>>>> conversion.
>>>
>>> Concretely, here is the current list of 664 checkme: annotations where
>>> something was suspicious about the PR number (either component mismatch or
>>> resolved as INVALID).  Would some people like to volunteer to pick up
>>> sections of this list and, for their section, produce a list of SVN
>>> revisions (at the end of the checkme line) for which the PR number appears
>>> to be correct, and a list of mappings from SVN revision to correct PR
>>> number when the PR number appears to be wrong?  For any that don't get
>>> reviewed like that we can easily make the script, for the final
>>> conversion, decline to add a new summary line for any commit where the PR
>>> number is suspicious.
>>
>> Here's a slightly shorter version with 644 checkme: annotations, after
>> adding a few more component aliases to the script (e.g., no longer
>> considering it suspicious if the log message says PR g++/something and
>> that PR is in the component that's actually called c++).
> 
> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
> Line 326: lto SVN r196613, PR number is correct
> Line 411: libstdc++ SVN r219147, PR number is correct
> 
> 
> How do you want the mapping from SVN revision to correct PR to be expressed?
> 
> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 39238)
> Line 608: lto SVN r268728 should be PR 87089 (not 87809)
> Line 616: lto SVN r269799 should be PR 87089 (not 87809)
> 

Best of all would be a pull request on 
https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py 
directly.

Second best would be something like

whitelist:

"<svn-revnumber>", "<svn-revnumber>",

etc, where svn-revnumber is the revision number in svn as reported in 
the checkme above but without the leading 'r'

and

Change:

    "<svn-revnumber>": {"PR": "<correct-bugid>"},
    ....

where svn-revnumber is as before, and <correct-bugid> is the the PR 
number that should have been used.

The above can then be pasted quickly into the script to update it.

R.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/12/2019 11:50, Richard Earnshaw (lists) wrote:
> On 19/12/2019 09:27, Jonathan Wakely wrote:
>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> 
>> wrote:
>>>
>>> On Wed, 18 Dec 2019, Joseph Myers wrote:
>>>
>>>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
>>>>
>>>>> I've attached a sample from the start of the fixed list - the full 
>>>>> list is far
>>>>> too big to post to give a flavour of how the script currently 
>>>>> works.  Note
>>>>> that annotations of the form [checkme: ....] in the summary are for 
>>>>> diagnostic
>>>>> purposes.  These are where heuristics suggest that there's a higher 
>>>>> than
>>>>> normal chance that the PR number is incorrect and that manual 
>>>>> auditing is
>>>>> recommended.  Such annotations would not be appropriate in the final
>>>>> conversion.
>>>>
>>>> Concretely, here is the current list of 664 checkme: annotations where
>>>> something was suspicious about the PR number (either component 
>>>> mismatch or
>>>> resolved as INVALID).  Would some people like to volunteer to pick up
>>>> sections of this list and, for their section, produce a list of SVN
>>>> revisions (at the end of the checkme line) for which the PR number 
>>>> appears
>>>> to be correct, and a list of mappings from SVN revision to correct PR
>>>> number when the PR number appears to be wrong?  For any that don't get
>>>> reviewed like that we can easily make the script, for the final
>>>> conversion, decline to add a new summary line for any commit where 
>>>> the PR
>>>> number is suspicious.
>>>
>>> Here's a slightly shorter version with 644 checkme: annotations, after
>>> adding a few more component aliases to the script (e.g., no longer
>>> considering it suspicious if the log message says PR g++/something and
>>> that PR is in the component that's actually called c++).
>>
>> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
>> Line 326: lto SVN r196613, PR number is correct
>> Line 411: libstdc++ SVN r219147, PR number is correct
>>
>>
>> How do you want the mapping from SVN revision to correct PR to be 
>> expressed?
>>
>> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 
>> 39238)
>> Line 608: lto SVN r268728 should be PR 87089 (not 87809)
>> Line 616: lto SVN r269799 should be PR 87089 (not 87809)
>>
> 
> Best of all would be a pull request on 
> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py 
> directly.
> 
> Second best would be something like
> 
> whitelist:
> 
> "<svn-revnumber>", "<svn-revnumber>",
> 
> etc, where svn-revnumber is the revision number in svn as reported in 
> the checkme above but without the leading 'r'
> 
> and
> 
> Change:
> 
>     "<svn-revnumber>": {"PR": "<correct-bugid>"},
>     ....
> 

There are two other actions that can be applied to commits, in the 
change section:

      "<svn-revnumber>" {"ignore": True},

(case is important: True, not true or TRUE), will force the script to 
ignore that commit entirely; you may end up with a pretty meaningless 
summary line, so this should be used sparingly if at all.

and

      "<svn-revnumber>" {"summary": "<new summary>"},

will use the specificed <new summary> as the summary line.

Given the number of commits, we can't rewrite everything, but if you see 
a summary that looks particularly wrong, we can insert something else 
using this override.

R.

> where svn-revnumber is as before, and <correct-bugid> is the the PR 
> number that should have been used.
> 
> The above can then be pasted quickly into the script to update it.
> 
> R.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 19/12/2019 09:27, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> wrote:
> >>
> >> On Wed, 18 Dec 2019, Joseph Myers wrote:
> >>
> >>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> >>>
> >>>> I've attached a sample from the start of the fixed list - the full list is far
> >>>> too big to post to give a flavour of how the script currently works.  Note
> >>>> that annotations of the form [checkme: ....] in the summary are for diagnostic
> >>>> purposes.  These are where heuristics suggest that there's a higher than
> >>>> normal chance that the PR number is incorrect and that manual auditing is
> >>>> recommended.  Such annotations would not be appropriate in the final
> >>>> conversion.
> >>>
> >>> Concretely, here is the current list of 664 checkme: annotations where
> >>> something was suspicious about the PR number (either component mismatch or
> >>> resolved as INVALID).  Would some people like to volunteer to pick up
> >>> sections of this list and, for their section, produce a list of SVN
> >>> revisions (at the end of the checkme line) for which the PR number appears
> >>> to be correct, and a list of mappings from SVN revision to correct PR
> >>> number when the PR number appears to be wrong?  For any that don't get
> >>> reviewed like that we can easily make the script, for the final
> >>> conversion, decline to add a new summary line for any commit where the PR
> >>> number is suspicious.
> >>
> >> Here's a slightly shorter version with 644 checkme: annotations, after
> >> adding a few more component aliases to the script (e.g., no longer
> >> considering it suspicious if the log message says PR g++/something and
> >> that PR is in the component that's actually called c++).
> >
> > Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
> > Line 326: lto SVN r196613, PR number is correct
> > Line 411: libstdc++ SVN r219147, PR number is correct
> >
> >
> > How do you want the mapping from SVN revision to correct PR to be expressed?
> >
> > Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 39238)
> > Line 608: lto SVN r268728 should be PR 87089 (not 87809)
> > Line 616: lto SVN r269799 should be PR 87089 (not 87809)
> >
>
> Best of all would be a pull request on
> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py
> directly.
>
> Second best would be something like
>
> whitelist:
>
> "<svn-revnumber>", "<svn-revnumber>",
>
> etc, where svn-revnumber is the revision number in svn as reported in
> the checkme above but without the leading 'r'
>
> and
>
> Change:
>
>     "<svn-revnumber>": {"PR": "<correct-bugid>"},
>     ....
>
> where svn-revnumber is as before, and <correct-bugid> is the the PR
> number that should have been used.
>
> The above can then be pasted quickly into the script to update it.
>
> R.

Thanks. I'm working through the first 100 lines in the file then.

If nobody else starts, I'll take the next 100, and so on.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/12/2019 12:23, Jonathan Wakely wrote:
> On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
>>
>> On 19/12/2019 09:27, Jonathan Wakely wrote:
>>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>
>>>> On Wed, 18 Dec 2019, Joseph Myers wrote:
>>>>
>>>>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
>>>>>
>>>>>> I've attached a sample from the start of the fixed list - the full list is far
>>>>>> too big to post to give a flavour of how the script currently works.  Note
>>>>>> that annotations of the form [checkme: ....] in the summary are for diagnostic
>>>>>> purposes.  These are where heuristics suggest that there's a higher than
>>>>>> normal chance that the PR number is incorrect and that manual auditing is
>>>>>> recommended.  Such annotations would not be appropriate in the final
>>>>>> conversion.
>>>>>
>>>>> Concretely, here is the current list of 664 checkme: annotations where
>>>>> something was suspicious about the PR number (either component mismatch or
>>>>> resolved as INVALID).  Would some people like to volunteer to pick up
>>>>> sections of this list and, for their section, produce a list of SVN
>>>>> revisions (at the end of the checkme line) for which the PR number appears
>>>>> to be correct, and a list of mappings from SVN revision to correct PR
>>>>> number when the PR number appears to be wrong?  For any that don't get
>>>>> reviewed like that we can easily make the script, for the final
>>>>> conversion, decline to add a new summary line for any commit where the PR
>>>>> number is suspicious.
>>>>
>>>> Here's a slightly shorter version with 644 checkme: annotations, after
>>>> adding a few more component aliases to the script (e.g., no longer
>>>> considering it suspicious if the log message says PR g++/something and
>>>> that PR is in the component that's actually called c++).
>>>
>>> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
>>> Line 326: lto SVN r196613, PR number is correct
>>> Line 411: libstdc++ SVN r219147, PR number is correct
>>>
>>>
>>> How do you want the mapping from SVN revision to correct PR to be expressed?
>>>
>>> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 39238)
>>> Line 608: lto SVN r268728 should be PR 87089 (not 87809)
>>> Line 616: lto SVN r269799 should be PR 87089 (not 87809)
>>>
>>
>> Best of all would be a pull request on
>> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py
>> directly.
>>
>> Second best would be something like
>>
>> whitelist:
>>
>> "<svn-revnumber>", "<svn-revnumber>",
>>
>> etc, where svn-revnumber is the revision number in svn as reported in
>> the checkme above but without the leading 'r'
>>
>> and
>>
>> Change:
>>
>>      "<svn-revnumber>": {"PR": "<correct-bugid>"},
>>      ....
>>
>> where svn-revnumber is as before, and <correct-bugid> is the the PR
>> number that should have been used.
>>
>> The above can then be pasted quickly into the script to update it.
>>
>> R.
> 
> Thanks. I'm working through the first 100 lines in the file then.
> 
> If nobody else starts, I'll take the next 100, and so on.
> 

Great, thanks.

It might be useful if someone could start from the other end.  The later 
numbers will be most recent and the ones which are more likely to be 
relevant to users today.

My apologies that I'm not going to be able to contribute as much to this 
as I'd hoped; events have conspired against me this week and today is 
probably pretty much the only day that I'll be at a computer this side 
of the new year.

R.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 19/12/2019 12:23, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
> > <Richard.Earnshaw@arm.com> wrote:
> >>
> >> On 19/12/2019 09:27, Jonathan Wakely wrote:
> >>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> wrote:
> >>>>
> >>>> On Wed, 18 Dec 2019, Joseph Myers wrote:
> >>>>
> >>>>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> >>>>>
> >>>>>> I've attached a sample from the start of the fixed list - the full list is far
> >>>>>> too big to post to give a flavour of how the script currently works.  Note
> >>>>>> that annotations of the form [checkme: ....] in the summary are for diagnostic
> >>>>>> purposes.  These are where heuristics suggest that there's a higher than
> >>>>>> normal chance that the PR number is incorrect and that manual auditing is
> >>>>>> recommended.  Such annotations would not be appropriate in the final
> >>>>>> conversion.
> >>>>>
> >>>>> Concretely, here is the current list of 664 checkme: annotations where
> >>>>> something was suspicious about the PR number (either component mismatch or
> >>>>> resolved as INVALID).  Would some people like to volunteer to pick up
> >>>>> sections of this list and, for their section, produce a list of SVN
> >>>>> revisions (at the end of the checkme line) for which the PR number appears
> >>>>> to be correct, and a list of mappings from SVN revision to correct PR
> >>>>> number when the PR number appears to be wrong?  For any that don't get
> >>>>> reviewed like that we can easily make the script, for the final
> >>>>> conversion, decline to add a new summary line for any commit where the PR
> >>>>> number is suspicious.
> >>>>
> >>>> Here's a slightly shorter version with 644 checkme: annotations, after
> >>>> adding a few more component aliases to the script (e.g., no longer
> >>>> considering it suspicious if the log message says PR g++/something and
> >>>> that PR is in the component that's actually called c++).
> >>>
> >>> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
> >>> Line 326: lto SVN r196613, PR number is correct
> >>> Line 411: libstdc++ SVN r219147, PR number is correct
> >>>
> >>>
> >>> How do you want the mapping from SVN revision to correct PR to be expressed?
> >>>
> >>> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 39238)
> >>> Line 608: lto SVN r268728 should be PR 87089 (not 87809)
> >>> Line 616: lto SVN r269799 should be PR 87089 (not 87809)
> >>>
> >>
> >> Best of all would be a pull request on
> >> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py
> >> directly.
> >>
> >> Second best would be something like
> >>
> >> whitelist:
> >>
> >> "<svn-revnumber>", "<svn-revnumber>",
> >>
> >> etc, where svn-revnumber is the revision number in svn as reported in
> >> the checkme above but without the leading 'r'
> >>
> >> and
> >>
> >> Change:
> >>
> >>      "<svn-revnumber>": {"PR": "<correct-bugid>"},
> >>      ....
> >>
> >> where svn-revnumber is as before, and <correct-bugid> is the the PR
> >> number that should have been used.
> >>
> >> The above can then be pasted quickly into the script to update it.
> >>
> >> R.
> >
> > Thanks. I'm working through the first 100 lines in the file then.
> >
> > If nobody else starts, I'll take the next 100, and so on.
> >
>
> Great, thanks.
>
> It might be useful if someone could start from the other end.  The later
> numbers will be most recent and the ones which are more likely to be
> relevant to users today.

And less likely to refer to egcs bugs and/or egcs patches from 1997
which are harder to find in our mailing lists archives!

Since nobody else has volunteered yet, maybe I should just start at
the end instead. All I've managed so far is to decide that line 1 is
too hard to track down and should get a {"summary":"..."} fixup
instead.

So I'll start with the LAST 100 lines.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/12/2019 12:35, Jonathan Wakely wrote:
> On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
> <Richard.Earnshaw@arm.com> wrote:
>>
>> On 19/12/2019 12:23, Jonathan Wakely wrote:
>>> On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
>>> <Richard.Earnshaw@arm.com> wrote:
>>>>
>>>> On 19/12/2019 09:27, Jonathan Wakely wrote:
>>>>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> wrote:
>>>>>>
>>>>>> On Wed, 18 Dec 2019, Joseph Myers wrote:
>>>>>>
>>>>>>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
>>>>>>>
>>>>>>>> I've attached a sample from the start of the fixed list - the full list is far
>>>>>>>> too big to post to give a flavour of how the script currently works.  Note
>>>>>>>> that annotations of the form [checkme: ....] in the summary are for diagnostic
>>>>>>>> purposes.  These are where heuristics suggest that there's a higher than
>>>>>>>> normal chance that the PR number is incorrect and that manual auditing is
>>>>>>>> recommended.  Such annotations would not be appropriate in the final
>>>>>>>> conversion.
>>>>>>>
>>>>>>> Concretely, here is the current list of 664 checkme: annotations where
>>>>>>> something was suspicious about the PR number (either component mismatch or
>>>>>>> resolved as INVALID).  Would some people like to volunteer to pick up
>>>>>>> sections of this list and, for their section, produce a list of SVN
>>>>>>> revisions (at the end of the checkme line) for which the PR number appears
>>>>>>> to be correct, and a list of mappings from SVN revision to correct PR
>>>>>>> number when the PR number appears to be wrong?  For any that don't get
>>>>>>> reviewed like that we can easily make the script, for the final
>>>>>>> conversion, decline to add a new summary line for any commit where the PR
>>>>>>> number is suspicious.
>>>>>>
>>>>>> Here's a slightly shorter version with 644 checkme: annotations, after
>>>>>> adding a few more component aliases to the script (e.g., no longer
>>>>>> considering it suspicious if the log message says PR g++/something and
>>>>>> that PR is in the component that's actually called c++).
>>>>>
>>>>> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
>>>>> Line 326: lto SVN r196613, PR number is correct
>>>>> Line 411: libstdc++ SVN r219147, PR number is correct
>>>>>
>>>>>
>>>>> How do you want the mapping from SVN revision to correct PR to be expressed?
>>>>>
>>>>> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 39238)
>>>>> Line 608: lto SVN r268728 should be PR 87089 (not 87809)
>>>>> Line 616: lto SVN r269799 should be PR 87089 (not 87809)
>>>>>
>>>>
>>>> Best of all would be a pull request on
>>>> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py
>>>> directly.
>>>>
>>>> Second best would be something like
>>>>
>>>> whitelist:
>>>>
>>>> "<svn-revnumber>", "<svn-revnumber>",
>>>>
>>>> etc, where svn-revnumber is the revision number in svn as reported in
>>>> the checkme above but without the leading 'r'
>>>>
>>>> and
>>>>
>>>> Change:
>>>>
>>>>       "<svn-revnumber>": {"PR": "<correct-bugid>"},
>>>>       ....
>>>>
>>>> where svn-revnumber is as before, and <correct-bugid> is the the PR
>>>> number that should have been used.
>>>>
>>>> The above can then be pasted quickly into the script to update it.
>>>>
>>>> R.
>>>
>>> Thanks. I'm working through the first 100 lines in the file then.
>>>
>>> If nobody else starts, I'll take the next 100, and so on.
>>>
>>
>> Great, thanks.
>>
>> It might be useful if someone could start from the other end.  The later
>> numbers will be most recent and the ones which are more likely to be
>> relevant to users today.
> 
> And less likely to refer to egcs bugs and/or egcs patches from 1997
> which are harder to find in our mailing lists archives!
> 
> Since nobody else has volunteered yet, maybe I should just start at
> the end instead. All I've managed so far is to decide that line 1 is
> too hard to track down and should get a {"summary":"..."} fixup
> instead.
> 
> So I'll start with the LAST 100 lines.
> 

Another approach might be to do a quick triage and cull out (whitelist) 
the ones that are "obviously correct".  You can often tell by reading 
the summary itself that it really does correspond to the commit.  Then 
we'd be left with a shorter list where things really do need further 
digging.  In the worst case we can just do as Joseph suggests and 
implement a policy ignore for those in the final conversion (I already 
do that for PR numbers <1000 since there was more than one gnats DB at 
that time and the PR numbers just do not line up reliably enough).

R.

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 12:42, Richard Earnshaw (lists)
<Richard.Earnshaw@arm.com> wrote:
>
> On 19/12/2019 12:35, Jonathan Wakely wrote:
> > On Thu, 19 Dec 2019 at 12:33, Richard Earnshaw (lists)
> > <Richard.Earnshaw@arm.com> wrote:
> >>
> >> On 19/12/2019 12:23, Jonathan Wakely wrote:
> >>> On Thu, 19 Dec 2019 at 11:50, Richard Earnshaw (lists)
> >>> <Richard.Earnshaw@arm.com> wrote:
> >>>>
> >>>> On 19/12/2019 09:27, Jonathan Wakely wrote:
> >>>>> On Thu, 19 Dec 2019 at 00:02, Joseph Myers <joseph@codesourcery.com> wrote:
> >>>>>>
> >>>>>> On Wed, 18 Dec 2019, Joseph Myers wrote:
> >>>>>>
> >>>>>>> On Mon, 18 Nov 2019, Richard Earnshaw (lists) wrote:
> >>>>>>>
> >>>>>>>> I've attached a sample from the start of the fixed list - the full list is far
> >>>>>>>> too big to post to give a flavour of how the script currently works.  Note
> >>>>>>>> that annotations of the form [checkme: ....] in the summary are for diagnostic
> >>>>>>>> purposes.  These are where heuristics suggest that there's a higher than
> >>>>>>>> normal chance that the PR number is incorrect and that manual auditing is
> >>>>>>>> recommended.  Such annotations would not be appropriate in the final
> >>>>>>>> conversion.
> >>>>>>>
> >>>>>>> Concretely, here is the current list of 664 checkme: annotations where
> >>>>>>> something was suspicious about the PR number (either component mismatch or
> >>>>>>> resolved as INVALID).  Would some people like to volunteer to pick up
> >>>>>>> sections of this list and, for their section, produce a list of SVN
> >>>>>>> revisions (at the end of the checkme line) for which the PR number appears
> >>>>>>> to be correct, and a list of mappings from SVN revision to correct PR
> >>>>>>> number when the PR number appears to be wrong?  For any that don't get
> >>>>>>> reviewed like that we can easily make the script, for the final
> >>>>>>> conversion, decline to add a new summary line for any commit where the PR
> >>>>>>> number is suspicious.
> >>>>>>
> >>>>>> Here's a slightly shorter version with 644 checkme: annotations, after
> >>>>>> adding a few more component aliases to the script (e.g., no longer
> >>>>>> considering it suspicious if the log message says PR g++/something and
> >>>>>> that PR is in the component that's actually called c++).
> >>>>>
> >>>>> Line 18: c++ SVN r116634, looks suspicious, but PR number is correct.
> >>>>> Line 326: lto SVN r196613, PR number is correct
> >>>>> Line 411: libstdc++ SVN r219147, PR number is correct
> >>>>>
> >>>>>
> >>>>> How do you want the mapping from SVN revision to correct PR to be expressed?
> >>>>>
> >>>>> Line 19: the correct PR for fortran SVN r120056 is fortran/30238 (not 39238)
> >>>>> Line 608: lto SVN r268728 should be PR 87089 (not 87809)
> >>>>> Line 616: lto SVN r269799 should be PR 87089 (not 87809)
> >>>>>
> >>>>
> >>>> Best of all would be a pull request on
> >>>> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py
> >>>> directly.
> >>>>
> >>>> Second best would be something like
> >>>>
> >>>> whitelist:
> >>>>
> >>>> "<svn-revnumber>", "<svn-revnumber>",
> >>>>
> >>>> etc, where svn-revnumber is the revision number in svn as reported in
> >>>> the checkme above but without the leading 'r'
> >>>>
> >>>> and
> >>>>
> >>>> Change:
> >>>>
> >>>>       "<svn-revnumber>": {"PR": "<correct-bugid>"},
> >>>>       ....
> >>>>
> >>>> where svn-revnumber is as before, and <correct-bugid> is the the PR
> >>>> number that should have been used.
> >>>>
> >>>> The above can then be pasted quickly into the script to update it.
> >>>>
> >>>> R.
> >>>
> >>> Thanks. I'm working through the first 100 lines in the file then.
> >>>
> >>> If nobody else starts, I'll take the next 100, and so on.
> >>>
> >>
> >> Great, thanks.
> >>
> >> It might be useful if someone could start from the other end.  The later
> >> numbers will be most recent and the ones which are more likely to be
> >> relevant to users today.
> >
> > And less likely to refer to egcs bugs and/or egcs patches from 1997
> > which are harder to find in our mailing lists archives!
> >
> > Since nobody else has volunteered yet, maybe I should just start at
> > the end instead. All I've managed so far is to decide that line 1 is
> > too hard to track down and should get a {"summary":"..."} fixup
> > instead.
> >
> > So I'll start with the LAST 100 lines.
> >
>
> Another approach might be to do a quick triage and cull out (whitelist)
> the ones that are "obviously correct".  You can often tell by reading
> the summary itself that it really does correspond to the commit.  Then
> we'd be left with a shorter list where things really do need further
> digging.  In the worst case we can just do as Joseph suggests and
> implement a policy ignore for those in the final conversion (I already
> do that for PR numbers <1000 since there was more than one gnats DB at
> that time and the PR numbers just do not line up reliably enough).
>
> R.

It might be reasonable to assume rtl-optimization and
tree-optimization are aliases, and not treat it as suspicious if those
two appear mixed up. And anything where bugzilla has component debug
or lto and the commit is tree-optimization is probably OK too (that
seems to be the case for several so far).

We might want to change the component in bugzilla for these:

92324 from c to tree-optimization
91763 from go to lto
91772 from lto to debug
91137 from rtl-optimization to tree-optimization
91445 from c++ to tree-optimization
90577 from middle-end to fortran
90716 from debug to tree-optimization
90273 from debug to tree-optimization
90194 from debug to middle-end

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:

> Best of all would be a pull request on
> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly.

Note if doing that, it helps to check "Allow commits from members who can 
merge to the target branch." when creating the merge request (that allows 
using GitLab's automated rebasing when merging a merge request created 
against a revision of master that's no longer the most recent revision).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/12/2019 11:16, Jakub Jelinek wrote:
> On Thu, Dec 19, 2019 at 12:01:28AM +0000, Joseph Myers wrote:
>> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277822])
>> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277955])
>> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r277958])
>> re PR c/92324 (ICE in expand_direct_optab_fn, at internal-fn.c:2890 [checkme: tree-optimization SVN r278289])
> 
> These are correct PR numbers, guess easiest check would be change c ->
> tree_optimization in the bugzilla to match what the bug really was.
> 
> 	Jakub
> 

Yes, we can certainly fix the bugzilla entries if that's easier.  To 
pick the changes up we'd have to rebuild the cache that my scripts use 
to avoid hammering the bugzilla service, but Joseph can do that now 
successfully, so it shouldn't be a problem as long as we know that needs 
doing.

R.

[not using the cache risks the PR data not being pulled properly during 
a conversion run due to network or load-dependent issues on the gcc server].

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 14:29, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > Best of all would be a pull request on
> > https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly.
>
> Note if doing that, it helps to check "Allow commits from members who can
> merge to the target branch." when creating the merge request (that allows
> using GitLab's automated rebasing when merging a merge request created
> against a revision of master that's no longer the most recent revision).

Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
(most of?) the most egregious ones, like fortran fixes with c++ PR
numbers and vice versa. Jakub and I have several whitelist commits
too, but I think they're all less critical (as mentioned previously,
most of them are unimportant differences like rtl-optimization vs
tree-optimization, or debug vs lto, or simply that  the Bugzilla
component has been changed since the commit was done and the commit
was actually right at the time).

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/12/2019 15:17, Jonathan Wakely wrote:
> On Thu, 19 Dec 2019 at 14:29, Joseph Myers <joseph@codesourcery.com> wrote:
>>
>> On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
>>
>>> Best of all would be a pull request on
>>> https://gitlab.com/esr/gcc-conversion/tree/master to update bugdb.py directly.
>>
>> Note if doing that, it helps to check "Allow commits from members who can
>> merge to the target branch." when creating the merge request (that allows
>> using GitLab's automated rebasing when merging a merge request created
>> against a revision of master that's no longer the most recent revision).
> 
> Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> (most of?) the most egregious ones, like fortran fixes with c++ PR
> numbers and vice versa. Jakub and I have several whitelist commits
> too, but I think they're all less critical (as mentioned previously,
> most of them are unimportant differences like rtl-optimization vs
> tree-optimization, or debug vs lto, or simply that  the Bugzilla
> component has been changed since the commit was done and the commit
> was actually right at the time).
> 

Merged

Re: Commit messages and the move to git

[Jonathan Wakely]

These scraped "INVALID" as the component from the changelog, because
it said "libgfortran/24685":

revert: re PR libfortran/24685 (real(16) formatted input is broken for
huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN
r142840])
revert: re PR libfortran/24685 (real(16) formatted input is broken for
huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN
r142841])

Shouldn't that be handled by the "compalias" dict?

Why are these invalid? The changelogs look OK:
re PR c++/46134 (constexpr vs. defaulted ctor [checkme: INVALID SVN r166171])
re PR c/11586 (after call sigaction, system() return wrong status
[checkme: INVALID SVN r187542])
re PR target/86677 (popcount builtin detection is breaking some kernel
build [checkme: INVALID SVN r266039])

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 19 Dec 2019, Jonathan Wakely wrote:

> These scraped "INVALID" as the component from the changelog, because
> it said "libgfortran/24685":

"INVALID" means the PR was closed as INVALID rather than FIXED, which 
makes it suspect for a commit to claim to be fixing it.  (Though since 
those are marked as "revert", they're probably OK and should be 
whitelisted.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 15:47, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > These scraped "INVALID" as the component from the changelog, because
> > it said "libgfortran/24685":
>
> "INVALID" means the PR was closed as INVALID rather than FIXED, which
> makes it suspect for a commit to claim to be fixing it.  (Though since
> those are marked as "revert", they're probably OK and should be
> whitelisted.)

Aha, thanks.

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/12/2019 15:44, Jonathan Wakely wrote:
> These scraped "INVALID" as the component from the changelog, because
> it said "libgfortran/24685":
> 
> revert: re PR libfortran/24685 (real(16) formatted input is broken for
> huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN
> r142840])
> revert: re PR libfortran/24685 (real(16) formatted input is broken for
> huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN
> r142841])
> 
> Shouldn't that be handled by the "compalias" dict?
> 
> Why are these invalid? The changelogs look OK:
> re PR c++/46134 (constexpr vs. defaulted ctor [checkme: INVALID SVN r166171])
> re PR c/11586 (after call sigaction, system() return wrong status
> [checkme: INVALID SVN r187542])
> re PR target/86677 (popcount builtin detection is breaking some kernel
> build [checkme: INVALID SVN r266039])
> 

INVALID means the PR was closed as invalid, which seems an suspect 
closure state for a PR that has had a patch installed.  In some cases 
the bug really was invalid and the commit is just some doc or other type 
cleanup, but it's often hard to be sure in the automated code, so it's 
flagged up for manual checking.

R.

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:

> > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > numbers and vice versa. Jakub and I have several whitelist commits
> > too, but I think they're all less critical (as mentioned previously,
> > most of them are unimportant differences like rtl-optimization vs
> > tree-optimization, or debug vs lto, or simply that  the Bugzilla
> > component has been changed since the commit was done and the commit
> > was actually right at the time).
> > 
> 
> Merged

And I've fixed up some Python syntax there (commas that needed to be 
colons, between the commit number and the fixup information).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 19 Dec 2019, Jonathan Wakely wrote:

> It might be reasonable to assume rtl-optimization and
> tree-optimization are aliases, and not treat it as suspicious if those
> two appear mixed up. And anything where bugzilla has component debug
> or lto and the commit is tree-optimization is probably OK too (that
> seems to be the case for several so far).

I've added those aliases (and the "tree-optimizatin" typo that appears a 
few times).  The case of (lto, tree-optimization) was already listed as an 
alias.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Richard Earnshaw (lists)]

On 19/12/2019 16:00, Joseph Myers wrote:
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> 
>> It might be reasonable to assume rtl-optimization and
>> tree-optimization are aliases, and not treat it as suspicious if those
>> two appear mixed up. And anything where bugzilla has component debug
>> or lto and the commit is tree-optimization is probably OK too (that
>> seems to be the case for several so far).
> 
> I've added those aliases (and the "tree-optimizatin" typo that appears a
> few times).  The case of (lto, tree-optimization) was already listed as an
> alias.
> 

Aliases are uni-directional.  You might need the reverse as well.

R.

Re: Commit messages and the move to git

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

On Thu, 19 Dec 2019 at 15:49, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
>
> > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > > numbers and vice versa. Jakub and I have several whitelist commits
> > > too, but I think they're all less critical (as mentioned previously,
> > > most of them are unimportant differences like rtl-optimization vs
> > > tree-optimization, or debug vs lto, or simply that  the Bugzilla
> > > component has been changed since the commit was done and the commit
> > > was actually right at the time).
> > >
> >
> > Merged
>
> And I've fixed up some Python syntax there (commas that needed to be
> colons, between the commit number and the fixup information).

Thanks.

I'm afraid it was too mind-numbing to just work through the list from
bottom to top. Jakub and I found some problems and some that can be
whitelisted. I submitted another merge request.

I've attached an updated list to this mail, which removes the items
we've analysed. There are 531 remaining.

[-- Attachment #2: tocheck2.txt --]
[-- Type: text/plain, Size: 59335 bytes --]

re PR rtl-optimization/13024 (gcj can't build current rhug [checkme: java SVN r73752])
backport: re PR rtl-optimization/12816 (internal compiler error pari-2.1.5/Olinux-i686 [checkme: c++ SVN r75851])
revert: re PR tree-optimization/16115 (double-destruction problem with argument passing via temporary (breaks auto_ptr) [checkme: c++ SVN r84147])
re PR tree-optimization/15262 ([tree-ssa] Alias analyzer cannot handle addressable fields [checkme: c SVN r86398])
re PR rtl-optimization/15857 (Wrong code with optimization >= -O1 [checkme: c++ SVN r87429])
re PR c/16403 (Floating-point assignment to int is inconsistent [checkme: INVALID SVN r94142])
re PR c++/20505 (internal error when compiling with -ggdb2 and no error with -ggdb1 [checkme: debug SVN r97528])
re PR rtl-optimization/19210 (not using do-loop for some loops [checkme: tree-optimization SVN r102225])
re PR tree-optimization/21562 (Quiet bad codegen (unrolling + tail call interaction) [checkme: c SVN r103245])
re PR c/21419 (Accepts writting to const via asm [checkme: tree-optimization SVN r104991])
re PR awt/26641 (AWT mouse event handling regression [checkme: libgcj SVN r112464])
re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114637])
re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114639])
re PR middle-end/25505 (gcc uses way too much stack space for this code [checkme: c++ SVN r116634])
re PR libstdc++/39238 (trunk revision 144279 - cfenv:54: error: ‘::fenv_t’ has not been declared [checkme: fortran SVN r120056])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121666])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121667])
re PR debug/33739 (Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin [checkme: fortran SVN r130244])
re PR c++/31863 (g++-4.1: out of memory with -O1/-O2 [checkme: middle-end SVN r131405])
re PR c/34601 (ICE with undefined enum [checkme: middle-end SVN r131506])
re PR middle-end/34668 (ICE in find_compatible_field with -combine [checkme: c SVN r131572])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131649])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131670])
re PR tree-optimization/34885 (ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574 [checkme: c SVN r131694])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r131719])
re PR c++/34953 (ICE on destructor + noreturn-function at -O3 [checkme: middle-end SVN r131782])
re PR translation/35002 (Incorrect spelling of "hottest" [checkme: c SVN r131940])
re PR driver/30330 (-Wdeprecated is not documented [checkme: documentation SVN r132131])
re PR tree-optimization/33512 (Simple bitwise simplification missed [checkme: rtl-opt SVN r132575])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133106])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133108])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133195])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133220])
re PR rtl-optimization/19580 (missed load/store motion [checkme: tree-optimization SVN r133683])
re PR preprocessor/34866 (valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c [checkme: libcpp SVN r134421])
re PR preprocessor/15500 (gcc ignores locale when converting wide string literals to wchar_t strings [checkme: libcpp SVN r134441])
re PR preprocessor/33415 (Can't compile .cpp file with UTF-8 BOM. [checkme: libcpp SVN r134507])
re PR c++/35652 (offset warning should be given in the front-end [checkme: c SVN r134714])
re PR fortran/36117 (Use MPFR for bessel function (optimization, rejects valid F2008) [checkme: middle-end SVN r135113])
re PR c++/36185 (wrong code with  -O2 -fgcse-sm [checkme: rtl-optimization SVN r135159])
re PR c++/35336 (Broken diagnostic: 'bit_field_ref' not supported by dump_expr [checkme: middle-end SVN r136662])
re PR c++/36460 (No space between >'s not always handled in C++0x [checkme: c SVN r136919])
re PR middle-end/36571 (Default untyped return for AVR is byte register. [checkme: c SVN r136926])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r136989])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r137001])
re PR tree-optimization/34371 (verify_stmts failed (incorrect sharing of tree nodes) [checkme: fortran SVN r137088])
re PR rtl-optimization/36672 (IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829 [checkme: preprocessor SVN r137581])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r137793])
re PR ada/36957 (ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge [checkme: tree-optimization SVN r138217])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r138293])
re PR middle-end/36633 (warning "array subscript is below array bounds" on delete [] with -O2, -Wall [checkme: c++ SVN r138425])
re PR c++/17880 (-Wsequence-point doesn't warn inside if, while, do conditions, for beg/cond/end expressions etc. [checkme: c SVN r138904])
re PR c++/28152 (Diagnostic about wrong use _Complex prints __complex__ [checkme: c SVN r139097])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r139159])
re PR c++/8895 (ICE on invalid template default value specification [checkme: libgcj SVN r139492])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139784])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139786])
re PR ada/37328 (ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747 [checkme: tree-optimization SVN r139931])
re PR middle-end/18071 (-Winline does not respect -fno-default-inline [checkme: c++ SVN r140418])
re PR debug/37410 (DW_TAG_imported_module is not in its DW_TAG_lexical_block [checkme: c++ SVN r140895])
re PR middle-end/29609 (Even with  -O0 -g gcc optimizes a goto away and I cannot debug [checkme: debug SVN r140948])
re PR tree-optimization/37568 (ICE returning a struct [checkme: c++ SVN r141010])
re PR debug/27017 (Debug information for static local class members are not emitted [checkme: c++ SVN r141829])
re PR debug/27574 (MIssing debug info at -O0 for a local variable in a C++ constructor [checkme: c++ SVN r141984])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142840])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142841])
re PR middle-end/36191 (can't use complex in a eh region if non-call-exceptions is enabled [checkme: c++ SVN r142950])
re PR tree-optimization/35805 ([ira] error in start_allocno_priorities, at ira-color.c:1806 [checkme: rtl-optimization SVN r143027])
re PR tree-optimization/38385 (ICE with -O2 -ftree-loop-distribution [checkme: middlend SVN r143291])
re PR c++/38908 (Unexplained "'<anonymous>' is used uninitialized in this function" warning in cc1plus -m64 [checkme: middle-end SVN r143722])
re PR c++/29027 (template conversion specialization found by using declaration [checkme: c SVN r144443])
re PR c++/29027 (template conversion specialization found by using declaration [checkme: c SVN r145422])
re PR c++/8781 (Pessimization of C++ (functional) code [checkme: tree-optimization SVN r145533])
re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145569])
backport: re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145574])
re PR middle-end/39614 (Internal error compiling CSiBE [checkme: c SVN r145737])
re PR rtl-optimization/37377 (Bootstrap failure compiling libgcc [checkme: fortran SVN r145965])
re PR c/39928 (gimplify_expr failure [checkme: middle-end SVN r146846])
re PR java/39940 (failure in jc1 on i686-apple-darwin9 host [checkme: tree-optimization SVN r147065])
re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r147659])
re PR middle-end/39834 (verify_cgraph_node failed with -O3 -Winline [checkme: debug SVN r148292])
backport: re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r148469])
re PR tree-optimization/26854 (Inordinate compile times on large routines [checkme: rtl-optimization SVN r149010])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149470])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149499])
re PR c/48388 (libgcc compilation causes a segfault [checkme: middle-end SVN r149516])
re PR middle-end/40867 (FAIL: StackTrace2 output - source compiled test [checkme: java SVN r150376])
re PR debug/40660 (Weird break points with 4.5, works with 4.4 [checkme: fortran SVN r151069])
re PR c/41163 (verify_gimple fails [checkme: middle-end SVN r151122])
re PR c++/41273 (ICE in add_virtual_operand, at tree-ssa-operands.c:638 [checkme: debug SVN r151454])
re PR c++/41144 (ice for legal code with -O2 in get_alias_set [checkme: middle-end SVN r151461])
re PR c/39779 (ICE shifting byte to the right with constant > 7FFFFFFF [checkme: rtl-optimization SVN r151573])
re PR c++/41275 (ICE: expand_expr_real_1, at expr.c:8416 [checkme: middle-end SVN r151631])
re PR c/41935 (ICE : tree check: expected integer_cst, have nop_expr in int_cst_value, at tree.c:8301 [checkme: middle-end SVN r153962])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154061])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154063])
re PR c++/26965 (Unnecessary debug info for unused consts in C++ [checkme: debug SVN r154157])
re PR c++/41961 (Internal error with -O3 and -ftree-parallelize-loops [checkme: tree-optimization SVN r154748])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154878])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154879])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154885])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154965])
re PR libstdc++/42381 (deque shouldn't reserve that much memory [checkme: libsdtc++ SVN r155271])
re PR tree-optimization/42386 (ICE in ipcp_iterate_stage, at ipa-cp.c:766 [checkme: c++ SVN r155321])
re PR rtl-optimization/42589 (bswap optimization does not work for 32bit (but for 64bit) on 64bit registers [checkme: tree-optimization SVN r155588])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r155765])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156010])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156016])
re PR tree-optimization/42685 ("-fcompare-debug failure" with "-O1 -funroll-loops" (2) [checkme: rtl-optimization SVN r156252])
re PR debug/42991 (cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s) [checkme: middle-end SVN r156575])
re PR c/43125 (Revision 156907 failed gcc.dg/attr-used.c [checkme: middle-end SVN r156927])
re PR rtl-optimization/40761 (IRA memory hog for insanely nested loops [checkme: tree-optimization SVN r157225])
re PR rtl-optimization/43058 (var-tracking uses up all virtual memory [checkme: debug SVN r157547])
re PR c/43661 (ice in fold_comparison, at fold-const.c:9579 [checkme: middle-end SVN r157984])
re PR debug/42425 (ICE declaring local class [checkme: lto SVN r158722])
re PR c++/43080 (ICE with anonymous union and -flto [checkme: lto SVN r158723])
re PR c++/40561 (code does not compile -- compiles fine when replacing != with !(==) [checkme: middle-end SVN r158778])
re PR c/44024 (missed optimization [checkme: middle-end SVN r159205])
re PR middle-end/44104 (New test failures [checkme: debug SVN r159367])
re PR c++/44256 (When using -flto and -fwhole-program the compiler/linker crash [checkme: lto SVN r159779])
re PR lto/44248 (-fcompare-debug failure with -flto/-fwhopr -g [checkme: debug SVN r161056])
backport: re PR middle-end/44104 (New test failures [checkme: debug SVN r161666])
re PR rtl-optimization/44479 (false dependencies are computed after vectorization [checkme: tree-optimization SVN r161802])
re PR fortran/44882 (Bogus types in references with mismatched commons [checkme: tree-optimization SVN r161990])
re PR debug/44689 (-fenable-icf-debug causes segfault in cp_function_decl_explicit_p [checkme: fortran SVN r162052])
re PR c++/36960 (Reference variable in virtually inherited base corrupted under optimization [checkme: tree-optimization SVN r162141])
re PR c++/45382 (internal compiler error: tree code ‘call_expr’ is not supported in gimple streams [checkme: lto SVN r165471])
re PR tree-optimization/20165 (Pointer does not really escape with write [checkme: fortran SVN r165559])
re PR rtl-optimization/45834 (Redundant inter-loop edges in DDG [checkme: c SVN r165781])
re PR c++/46134 (constexpr vs. defaulted ctor [checkme: INVALID SVN r166171])
re PR debug/46241 (ice in dwarf2out.c [checkme: middle-end SVN r166245])
re PR tree-optimization/46183 (ICE: in calc_dfs_tree, at dominance.c:396 with -O -fno-dse -fgcse -ftree-pre [checkme: rtl-optimization SVN r166316])
re PR rtl-optimization/33172 (Optimizer fails to elid away unreferenced static function [checkme: tree-optimize SVN r166557])
re PR fortran/38669 (Array bounds violation for arguments of elemental subroutine [checkme: tree-optimize SVN r166579])
re PR rtl-optimization/42889 ("-fcompare-debug failure (length)" with "-O1 -fgcse" [checkme: debug SVN r166719])
re PR middle-end/46297 (gfortran.dg/g77/980701-0.f FAILs with -Os -fno-asynchronous-unwind-tables [checkme: middle-end-optimization SVN r166905])
re PR rtl-optimization/46665 (two gfortran tests fail with -O[2s] -fipa-pta -fno-tree-ccp -fno-tree-forwprop [checkme: tree-optimization SVN r167176])
re PR driver/44986 (-fuse-linker-plugin -save-temps gives resolution file base name of last argument [checkme: lto SVN r167292])
re PR c++/44871 (Invalid type mismatches while merging C and C++ sources [checkme: lto SVN r167367])
re PR middle-end/46745 ('#'mem_ref' not supported by dump_expr#<expression error>' [checkme: c SVN r167433])
re PR driver/46760 (LTO bootstrap doesn't work with FDO [checkme: tree-optimization SVN r167458])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r167487])
re PR lto/46576 (BFD linker plugin generates bad executables [checkme: debug SVN r167738])
re PR middle-end/46885 (ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:251 with -ftree-parallelize-loops -g [checkme: debug SVN r167801])
re PR tree-optimization/46469 (ICE: verify_cgraph_node failed: inline clone is needed at -O [checkme: tree-optmization SVN r168598])
re PR c/32511 (GCC rejects inline+weak function [checkme: middle-end SVN r168652])
re PR tree-optimization/46583 (-fcompare-debug failure with -O -fno-inline -fipa-cp -fipa-cp-clone [checkme: debug SVN r169058])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169310])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169377])
re PR fortran/47293 (libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing [checkme: libquadmath SVN r169466])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169634])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169677])
re PR fortran/47293 (libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing [checkme: libquadmath SVN r169738])
re PR c++/47541 (For integer pointers, the value of ++*p  is not written back to memory [checkme: tree-optimization SVN r169740])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r169851])
re PR debug/47647 (BLOCKs are empty [checkme: lto SVN r170321])
re PR debug/47283 (ICE in refs_may_alias_p_1, at tree-ssa-alias.c [checkme: middle-end SVN r170650])
re PR c++/48073 (ICE with -flto in templated C++ code [checkme: lto SVN r170875])
re PR rtl-optimization/48037 (Missed optimization: unnecessary register moves [checkme: tree-optimization SVN r170986])
re PR c++/13954 ([tree-ssa] SRA does not work for classes that use inheritance with an empty base [checkme: tree-optimization SVN r170994])
re PR driver/46944 (gcc should accept -fuse-linker-plugin only if linker handles -plugin [checkme: lto SVN r171039])
re PR c/48146 (ICE tree check: expected ssa_name, have var_decl in has_zero_uses, at tree-flow-inline.h:342 [checkme: tree-optimization SVN r171045])
re PR c/48650 (valgrind: Invalid write of size 8 in build_string (tree.c:1524) [checkme: middle-end SVN r172642])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172649])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172650])
re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172706])
re PR debug/48207 (ICE in lhd_set_decl_assembler_name, at langhooks.c:158 [checkme: lto SVN r172708])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172765])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172766])
re PR c/47892 (Fails to vectorize comparison code, if-conversion fails [checkme: tree-optimization SVN r172774])
re PR debug/48703 (segfault in canonicalize_for_substitution [checkme: lto SVN r172830])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172963])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172964])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173876])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173877])
re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r173901])
backport: re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r174476])
re PR java/23754 (tree check error in check_inner_circular_reference [checkme: lto SVN r175174])
re PR middle-end/49373 (Many testcase failures [checkme: tree-optimize SVN r175336])
re PR rtl-optimization/49169 (ARM: optimisations strip the Thumb/ARM mode bit off function pointers [checkme: tree-optimization SVN r175427])
re PR rtl-optimization/49686 (CFI notes are missed for delayed slot [checkme: debug SVN r176091])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176448])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176481])
re PR tree-optimization/49957 (Fails to SLP in 410.bwaves [checkme: fortran SVN r177368])
re PR middle-end/37221 (Missed early loop-unroll optimization - causes 40% degradation on SPU [checkme: fortran SVN r177486])
re PR debug/50006 (ICE in in connect_traces, at dwarf2cfi.c:2677 [checkme: middle-end SVN r177764])
re PR rtl-optimization/50191 (Strange debug insn produced for TOC compiling 416.gamess with profile-generate [checkme: debug SVN r178625])
re PR libgomp/50386 (libgomp.h:87:5: error: unnamed struct/union that defines no instances [checkme: middle-end SVN r179285])
re PR c/50507 (Huge amount of memory used while building GCC4 [checkme: c++ SVN r180002])
re PR middle-end/49310 (Compile time hog in var-tracking emit [checkme: debug SVN r180194])
re PR driver/41844 (lto1: warning: unknown register name: line-length-none [checkme: lto SVN r180517])
re PR rtl-optimization/50765 (ICE: in expand_insn, at optabs.c:7681 with -ftree-vectorize -fno-tree-dce [checkme: tree-optimization SVN r181617])
re PR debug/51262 (ICE: SIGSEGV in primary_template_instantiation_p (pt.c:2874) with -flto -g [checkme: lto SVN r182221])
re PR debug/48354 (internal compiler error: in splice_child_die, at dwarf2out.c:8064 [checkme: lto SVN r182286])
re PR debug/51564 (ICE in force_type_die, at dwarf2out.c:19288 [checkme: lto SVN r182367])
re PR debug/51567 (ICE in splice_child_die, at dwarf2out.c:5009 with -flto -g [checkme: lto SVN r182377])
re PR tree-optimization/51557 (ICE: in maybe_record_trace_start, at dwarf2cfi.c:2244 with custom flags [checkme: debug SVN r182404])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r182524])
re PR debug/51650 (LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul [checkme: lto SVN r182625])
re PR c/51730 (autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7 [checkme: middle-end SVN r182830])
re PR c/8081 (ICE with variably sized types returned from nested functions [checkme: middle-end SVN r183153])
re PR c++/53207 (bool conversion on return [checkme: tree-optimization SVN r184623])
re PR c++/52582 (g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit) [checkme: middle-end SVN r185381])
re PR c++/52772 (internal compiler error: Segmentation fault [checkme: middle-end SVN r186011])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186494])
re PR tree-optimization/44688 (Excessive code-size growth at -O3 [checkme: rtl-optimization SVN r186585])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186593])
re PR c++/53050 (ssa_forward_propagate_and_combine: segmentation fault [checkme: tree-optimization SVN r186620])
re PR c/11586 (after call sigaction, system() return wrong status [checkme: INVALID SVN r187542])
re PR rtl-optimization/53373 (ICE on valid code with -mavx [checkme: rtl-optimzation SVN r187695])
re PR fortran/53148 (Incorrect intrinsic function parsing on labeled statements when compiled w/ -ffrontend-optimize [checkme: c SVN r187718])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187931])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187932])
re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188298])
re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188386])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188387])
backport: re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188615])
backport: re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188625])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188811])
re PR rtl-optimization/53706 (Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418) [checkme: debug SVN r189037])
re PR c/53937 (Pack'ing struct causes gcc to not recognize that an field's address is aligned [checkme: middle-end SVN r189458])
re PR web/53919 (Version-specific install instructions not available [checkme: c++ SVN r189545])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190533])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190534])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r191066])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191614])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191615])
re PR middle-end/53024 (Support vector_size that is not a power of 2 [checkme: c SVN r191800])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192119])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192121])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192122])
re PR lto/54980 (gimple check: expected gimple_cond(error_mark), have gimple_call() in gimple_cond_set_lhs, at gimple.h:2578 [checkme: tree-optimize SVN r192809])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193331])
re PR rtl-optimization/55154 (ICE: in curr_insn_transform, at lra-constraints.c:2702 with custom flags [checkme: tree-optimization SVN r193364])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193406])
re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r193649])
re PR tree-optimization/55052 (vect-widening tests are failing and giving wrong results [checkme: rtl-optimization SVN r193909])
re PR rtl-optimization/55717 (ICE in form_sum, at reload.c:5400 [checkme: debug SVN r194575])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r194680])
re PR tree-optimization/55875 (IVopts caused miscompilation [checkme: tree-optimiation SVN r195054])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r195173])
re PR libstdc++/51083 (TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained [checkme: tree-optimizatoin SVN r195274])
re PR rtl-optimization/55273 (ICE in iv_number_of_iterations, at loop-iv.c:2819 [checkme: tree-optimizatoin SVN r195275])
re PR libffi/56000 (FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test [checkme: middle-end SVN r195277])
re PR rtl-optimization/55270 (ICE in get_loop_body, at cfgloop.c:823 [checkme: tree-optimization SVN r195533])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195541])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195542])
re PR debug/54410 (doubled DW_TAG_template_type_param [checkme: c++ SVN r195613])
re PR sanitizer/55561 (TSAN: provide a TSAN instrumented libgomp [checkme: libgomp SVN r195618])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r195632])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195646])
backport: re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r195650])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195707])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195751])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195758])
re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r195796])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195844])
re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196133])
backport: re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r196141])
backport: re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196149])
re PR libstdc++/56557 (Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options [checkme: lto SVN r196613])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r196769])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197047])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197048])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197201])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197203])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197349])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197350])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197351])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197420])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197421])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197454])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198445])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198446])
re PR c++/57038 (Latest libreoffice compilation fails with enabled LTO [checkme: lto SVN r198917])
re PR tree-optimization/55177 (missed optimizations with __builtin_bswap [checkme: rtl-optimization SVN r199278])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199282])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199283])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199284])
re PR c++/57208 (Latest chromium compilation fails with enabled LTO [checkme: lto SVN r200468])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201696])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201697])
re PR c++/58201 (Undefined reference to `B::B(void const**)' [checkme: middle-end SVN r202298])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202496])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202498])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202564])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202565])
re PR c/20318 (RFE: add attribute to specify that a function never returns NULL [checkme: tree-optimization SVN r203316])
re PR c/52862 (ICE convert_to_pointer, at convert.c:50 [checkme: plugin SVN r204650])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205481])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205487])
backport: re PR target/59405 (Incorrect FP<->MMX transition during call/ret [checkme: INVALID SVN r205790])
re PR middle-end/59399 (ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow [checkme: sanitizer SVN r205888])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205991])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205993])
re PR fortran/45586 (ICE non-trivial conversion at assignment [checkme: lto SVN r206461])
re PR c++/58252 (ice in gimple_get_virt_method_for_binfo with -O2 [checkme: ipa SVN r206516])
re PR tree-optimization/46590 (long compile time with -O2 and many loops [checkme: rtl-optimization SVN r206663])
re PR fortran/59706 (ICE with do concurrent and internal subprogram [checkme: middle-end SVN r206732])
re PR ipa/59469 (LLVM build failure with gcc LTO [checkme: c++ SVN r207366])
re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r207695])
re PR fortran/60060 (lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096 [checkme: lto SVN r207715])
backport: re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r208366])
re PR c++/60474 (Crash in tree_class_check [checkme: middle-end SVN r208451])
re PR c++/60553 (segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO [checkme: middle-end SVN r208682])
re PR c++/60750 (double free after std::move on string inside throw when compiled with optimization [checkme: middle-end SVN r209179])
re PR libfortran/60706 (FAIL: gfortran.dg/size_kind_2.f90  -O   scan-tree-dump original "var2 = 42949673 00;" [checkme: middle-end SVN r209216])
re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209468])
backport: re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209630])
re PR debug/61070 (debug_bitmap writes to stdout [checkme: middle-end SVN r210098])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210181])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210203])
re PR c/61136 (ice in tree_nop_conversion [checkme: tree-optimization SVN r210312])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210426])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210472])
re PR c++/60189 (ICE with invalid use of _Cilk_sync [checkme: c SVN r210678])
re PR c++/60189 (ICE with invalid use of _Cilk_sync [checkme: c SVN r210680])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212174])
re PR middle-end/60226 (ICE initializing array of elements with too large alignment [checkme: c SVN r212346])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212436])
re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212521])
backport: re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212741])
re PR ipa/61921 (ICE: SIGSEGV in varpool_node::get_constructor(), at varpool.c:275 with -O2 -fipa-pta [checkme: tree-optimization SVN r213114])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r213308])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213491])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213492])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213812])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213901])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213904])
re PR tree-optimization/62079 (ICE: in calc_dfs_tree, at dominance.c:401 with -fnon-call-exceptions [checkme: rtl-optimization SVN r213950])
re PR preprocessor/60975 (-Wvariadic-macros does not print warning [checkme: c SVN r214200])
re PR c++/62175 (Internal compiler error in gimplify_modify_expr gimplify.c:4616 [checkme: tree-optimization SVN r214492])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214543])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214546])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r214678])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r215134])
re PR c++/63419 (verify_gimple failed: "vector CONSTRUCTOR element is not a GIMPLE value" [checkme: tree-optimization SVN r216138])
re PR c++/62127 (ICE with VLA in constructor [checkme: tree-optimization SVN r216150])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r216273])
re PR c/63554 (ice in "execute_todo, at passes.c:1797" with -O3 [checkme: middle-end SVN r216315])
re PR middle-end/63879 (ICE compiling Linux Kernel fs/ext3/namei.c with -fsanitize=undefined [checkme: sanitizer SVN r217766])
re PR tree-optimization/64004 ([5 Regressio] Build error in tree-ssa-loop-niter.c in maybe_lower_iteration_bound [checkme: java SVN r218018])
re PR tree-optimization/64121 (ICE: SSA corruption with -O -fsanitize=undefined [checkme: sanitizer SVN r218222])
re PR web/64468 (Incorrect indentation in Doxygen-generated sources of libstdc++ [checkme: libstdc++ SVN r219147])
re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220152])
re PR sanitizer/64717 (-fsanitize=vptr leads to warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized] [checkme: c++ SVN r220262])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220327])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220335])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220420])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220617])
backport: re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220622])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220624])
re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r221776])
re PR c++/65626 (ICE in fixup_noreturn_call called by tree-ssa-forwprop.c:2492 [checkme: middle-end SVN r221790])
re PR middle-end/65554 (ICE: verify_gimple failed [checkme: c++ SVN r221808])
re PR c++/65851 (ice in set_lattice_value at tree-ssa-cc p.c:535 [checkme: tree-optimization SVN r222510])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222514])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222843])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222849])
re PR rtl-optimization/66187 (wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu [checkme: tree-optimization SVN r223366])
re PR ipa/65701 (r221530 makes 187.facerec drop with -Ofast -flto on bdver2 [checkme: tree-optimization SVN r223528])
backport: re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r224090])
re PR debug/66503 (missing DW_AT_abstract_origin for cross-unit call sites [checkme: middle-end SVN r224372])
re PR rtl-optimization/66351 (r223883 miscompiles stage2 compiler on ia64 [checkme: ipa SVN r224719])
re PR preprocessor/53690 ([C++11] \u0000 and \U00000000 are wrongly encoded as U+0001. [checkme: c++ SVN r225353])
re PR ipa/66793 (ICE at -Os and above on x86_64-linux-gnu (verify_flow_info failed) [checkme: tree-optimization SVN r225546])
re PR lto/66468 (ICE in in check_die, at dwarf2out.c:5719 [checkme: debug SVN r226255])
re PR debug/67043 (-fcompare-debug failure with -O3 [checkme: tree-optimization SVN r226540])
re PR c/67107 (ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations [checkme: middle-end SVN r226609])
re PR c/67279 (-fsanitize=undefined spurious error: initializer element is not constant [checkme: sanitizer SVN r227491])
re PR c/48885 (missed optimization with restrict qualifier? [checkme: tree-optimization SVN r228073])
re PR fortran/67170 (PRE can't hoist out a readonly argument [checkme: tree-optimization SVN r228244])
re PR c/67882 (surprising offsetof result on an invalid array member without diagnostic [checkme: c++-common SVN r229717])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230897])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230901])
re PR c++/67581 (ICE on transparent union with -g enabled on x86_64-linux-gnu (verify_type failed) [checkme: c SVN r231048])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231100])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231110])
re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231217])
re PR middle-end/68656 (warning about disabled var-tracking uses odd location info [checkme: c SVN r231292])
re PR debug/66688 (compare debug failure building Linux kernel on ppc64le [checkme: tree-optimization SVN r231644])
backport: re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231677])
re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r232122])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232169])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232171])
re PR tree-optimization/69164 (ICE in create_tmp_var, at gimple-expr.c:468 [checkme: c++ SVN r232187])
re PR debug/69077 (omnetpp ICEs with -flto -g [checkme: lto SVN r232272])
re PR c++/66487 (sanitizer/warnings for lifetime DSE [checkme: ipa SVN r232356])
re PR tree-optimization/69355 (Wrong results with -O1 optimization [checkme: c++ SVN r232663])
re PR c++/69267 ([cilkplus] ICE when calling a function with an empty class as an argument [checkme: cilkplus SVN r232887])
re PR middle-end/69643 (Address space discarded [checkme: c SVN r233189])
re PR middle-end/69537 (Incorrect -Wmaybe-uninitialized warning with enum variable [checkme: go SVN r233235])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233288])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233327])
re PR tree-optimization/69110 (execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2 [checkme: fortran SVN r233782])
re PR rtl-optimization/69052 (Performance regression after r229402. [checkme: tree-optimization SVN r233907])
re PR middle-end/70054 (GCC 6 gives a strict-aliasing warning on use of std::aligned_storage [checkme: c++ SVN r233961])
re PR sanitizer/70135 (-fsanitize=undefined causes static_assert to fail [checkme: c++ SVN r234064])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234248])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234249])
re PR tree-optimization/70144 (g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref" [checkme: c++ SVN r234297])
re PR middle-end/70280 (-fcompare-debug failure (length) with --param=integer-share-limit=4016 -mavx512bw [checkme: c SVN r234312])
re PR middle-end/70273 (FAIL: g++.dg/ext/label13a.C  -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev [checkme: c++ SVN r234386])
re PR preprocessor/69650 (ICE in linemap_line_start, at libcpp/line-map.c:803 [checkme: lto SVN r234481])
re PR middle-end/70307 (ICE: in gimplify_expr, at gimplify.c:10915 on valid code [checkme: c SVN r234706])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235063])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235065])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235081])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235318])
re PR go/49889 (Calling a function whose name is obscured by a local variable does not produce an error [checkme: middle-end SVN r235484])
re PR fortran/70931 (ICE with -g in native_encode_initializer, bei dwarf2out.c:17768 [checkme: middle-end SVN r235944])
re PR ada/70786 (Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available) [checkme: tree-optimization SVN r236086])
re PR middle-end/71249 (-Wswitch-unreachable false positive for a compound statement containing a used label [checkme: c SVN r236649])
re PR c++/61564 (#pragma GCC optimize ("-fno-lto") causes the compiler to crash [checkme: c SVN r237174])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r237840])
re PR debug/71667 (ICE in as_a, at is-a.h:192 w/ -g -O2 -ftree-vectorize [checkme: tree-optimization SVN r238160])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r238238])
re PR tree-optimization/68961 (Test case gcc.target/powerpc/pr60203.c fails since r231674 [checkme: rtl-optimization SVN r238268])
re PR middle-end/50060 (intrinsics not folded by the middle-end [checkme: c++ SVN r238520])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238579])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238580])
re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239855])
re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239904])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239930])
backport: re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239933])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240006])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240025])
re PR rtl-optimization/64316 (ICE in simplify_const_unary_operation after r218503 [checkme: ipa SVN r240081])
re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r240348])
re PR fortran/77678 (ICE in fold_read_from_constant_string, at fold-const.c:13706 [checkme: middle-end SVN r240351])
re PR rtl-optimization/77714 (Wrong code generation for gcc.c-torture/execute/pr51447.c [checkme: rlt-optimization SVN r240518])
re PR c++/78051 (error: dead STMT in EH table when using -O2 [checkme: tree-optimization SVN r241394])
re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r241912])
re PR tree-optimization/35503 (Warning about restricted pointers? [checkme: c SVN r242366])
re PR tree-optimization/66419 (FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution,  -O3 -g [checkme: debug SVN r243126])
re PR tree-optimization/78692 (ICE (segfault) [checkme: c++ SVN r243377])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r243387])
backport: re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r243549])
backport: re PR tree-optimization/77309 (wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: rtl-optimization SVN r243550])
re PR middle-end/78622 (-Wformat-length/-fprintf-return-value incorrect with overflow/wrapping [checkme: fortran SVN r243765])
re PR tree-optimization/78856 (wrong code at -O3 on x86_64-linux-gnu (in both 32-bit and 64-bit modes) [checkme: tree-optimizatin SVN r244045])
re PR tree-optimization/67955 (tree-dse does not use pointer info [checkme: tree-optimizatin SVN r244067])
re PR rtl-optimization/78812 (Wrong code generation due to hoisting memory load across function call [checkme: tree-optimizatin SVN r244093])
re PR middle-end/79089 (error: incorrect sharing of tree nodes [checkme: c SVN r244507])
re PR rtl-optimization/72488 (wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: tree-optimization SVN r244623])
re PR rtl-optimization/72488 (wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode) [checkme: tree-optimization SVN r244625])
backport: re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r244870])
re PR c++/79129 (ICE with -fdebug-types-section starting with r240578 [checkme: debug SVN r244955])
re PR rtl-optimization/71374 (ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190 [checkme: tree-optimization SVN r244991])
re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245053])
re PR tree-optimization/79347 (vect_do_peeling is messing up profile [checkme: tree-ssa SVN r245196])
re PR middle-end/56727 (Recursive call goes through the PLT unnecessarily [checkme: tree-ssa SVN r245359])
backport: re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245466])
re PR inline-asm/79552 (Wrong code generation due to -fschedule-insns, with __restrict__ and inline asm [checkme: tree-optimization SVN r245528])
re PR rtl-optimization/79286 (ira and lra wrong code at -O2 and -Os on i686-linux [checkme: rtl-optimizatoin SVN r245714])
re PR c/79731 (ICE: verify_gimple failed [checkme: middle-end SVN r245779])
re PR middle-end/79756 (ICE in execute_todo, at passes.c:2011 [checkme: c SVN r245838])
re PR fortran/79894 (ICE in gfc_add_modify_loc, at fortran/trans.c:159 [checkme: tree-optimization SVN r245923])
re PR c++/80075 (ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions [checkme: middle-end SVN r246223])
re PR middle-end/67338 (fold-const sanitizer runtime error  in roundup_loc [checkme: c SVN r246305])
re PR ipa/78644 (ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp [checkme: tree-optimization SVN r246534])
re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r246621])
re PR middle-end/80163 (ICE on hopefully valid code [checkme: c SVN r246876])
re PR c++/69953 (Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail [checkme: lto SVN r246899])
re PR debug/80453 (another compare-debug failure [checkme: tree-optimization SVN r247024])
re PR fortran/80494 (ICE in wide_int_to_tree [checkme: tree-optimization SVN r247095])
backport: re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r247694])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r248602])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r248612])
re PR sanitizer/81065 (UBSAN: false positive as a result of distribution involving different types [checkme: middle-end SVN r249144])
re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249174])
re PR sanitizer/81097 (UBSAN: false positive for not existing negation operator and a bogus message [checkme: middle-end SVN r249407])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249479])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249510])
re PR sanitizer/81505 (ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow [checkme: middle-end SVN r250494])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r250853])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r251143])
re PR c++/82054 (ICE in add_dwarf_attr with -fopenmp and -g [checkme: middle-end SVN r251559])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251661])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251711])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r252277])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r252458])
re PR debug/82144 (ICE in add_dwarf_attr with alignas [checkme: middle-end SVN r253134])
re PR c/82765 (ICE at -Os on valid code on x86_64-linux-gnu: in tree_to_shwi, at tree.c:6611 [checkme: middle-end SVN r254337])
re PR fortran/83017 (DO CONCURRENT not parallelizing [checkme: tree-optimization SVN r254867])
re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255354])
re PR tree-optimization/78496 (Missed opportunities for jump threading [checkme: tree-optimizatin SVN r255387])
re PR middle-end/83415 (ICE during gimplification of assignment to read-only vector [checkme: c SVN r255629])
re PR sanitizer/83388 (reference statement index not found error with -fsanitize=null [checkme: lto SVN r255694])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255722])
re PR ipa/81877 (Incorrect results with lto and -fipa-cp and -fipa-cp-clone [checkme: tree-optimization SVN r255776])
re PR c++/83482 (internal compiler error: Segmentation fault [checkme: tree-optimization SVN r255817])
re PR debug/83694 (New test case gcc.dg/pr83666.c from r256232 ICEs [checkme: middle-end SVN r256307])
re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256341])
re PR rtl-optimization/81308 (ICE in calc_dfs_tree, at dominance.c:458 [checkme: rtl-optimizatin SVN r256349])
re PR c++/80763 (-O3 causes error: inline clone in same comdat group list [checkme: ipa SVN r256369])
backport: re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256371])
re PR c++/86620 (__attribute__((no inline)) gives incorrect warning with overloaded functions [checkme: rtl-optimization SVN r256729])
re PR fortran/84000 (ICE in replace_loop_annotate, at tree-cfg.c:352 [checkme: middle-end SVN r257011])
re PR libgomp/84086 ([8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1 [checkme: tree-optimization SVN r257152])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257721])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257722])
re PR libgomp/84466 (libgomp.graphite/force-parallel-8.c fails starting with r257723 [checkme: tree-optimization SVN r258035])
re PR c/84607 (Side effects discarded in address computation inside 'if' [checkme: middle-end SVN r258061])
re PR debug/85176 (ICE in force_decl_die, at dwarf2out.c:25910 [checkme: lto SVN r259080])
re PR rtl-optimization/85302 (ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu [checkme: debug SVN r259311])
re PR c/86046 (ICE in execute_todo, at passes.c:2043 [checkme: tree-optimization SVN r261193])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r262042])
re PR debug/86523 (ICE in gen_member_die, at dwarf2out.c:24933 starting from r262560 [checkme: lto SVN r262696])
re PR debug/86456 (Segfault in switch_to_section at  gcc/varasm.c:7353 since r259317 [checkme: lto SVN r262819])
re PR lto/86654 (ICE in gen_member_die, at dwarf2out.c:24933 [checkme: debug SVN r262965])
re PR c++/78655 (gcc doesn't exploit the fact that the result of pointer addition can not be nullptr [checkme: tree-optimization SVN r263662])
re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r263967])
backport: re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r264107])
re PR middle-end/41453 (use INTENT(out) for optimization [checkme: fortran SVN r264506])
re PR c/87682 (gcc/mem-stats.h:172: possible broken comparison operator ? [checkme: middle-end SVN r265376])
re PR c++/87469 (ice in record_estimate, at tree-ssa-loop-niter.c:3271 [checkme: middle-end SVN r265605])
re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r265776])
re PR c/87953 (asan: stack-buffer-overflow in vectorizable_reduction [checkme: tree-optimization SVN r265964])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266014])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266015])
re PR target/86677 (popcount builtin detection is breaking some kernel build [checkme: INVALID SVN r266039])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266550])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266553])
re PR tree-optimization/88367 (-fno-delete-null-pointer-checks doesn't work properly [checkme: c SVN r266878])
re PR c/87944 (Wrong code with LRA pushing stack local variable [checkme: fortran SVN r267184])
re PR tree-optimization/88606 (ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR) [checkme: c SVN r268540])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268748])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268750])
re PR lto/89514 (-g -fdebug-types-section -flto gives 'Dwarf Error: bad length' in gdb [checkme: debug SVN r269250])
re PR rtl-optimization/89487 (ICE in expand_expr_addr_expr_1, at expr.c:7993 [checkme: tree-optimization SVN r269361])

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 16:26, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Thu, 19 Dec 2019 at 15:49, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> >
> > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > > > numbers and vice versa. Jakub and I have several whitelist commits
> > > > too, but I think they're all less critical (as mentioned previously,
> > > > most of them are unimportant differences like rtl-optimization vs
> > > > tree-optimization, or debug vs lto, or simply that  the Bugzilla
> > > > component has been changed since the commit was done and the commit
> > > > was actually right at the time).
> > > >
> > >
> > > Merged
> >
> > And I've fixed up some Python syntax there (commas that needed to be
> > colons, between the commit number and the fixup information).
>
> Thanks.
>
> I'm afraid it was too mind-numbing to just work through the list from
> bottom to top. Jakub and I found some problems

To be clear, by "problems" I mean entries that were indeed wrong and
need a fixup.

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 19 Dec 2019, Jonathan Wakely wrote:

> On Thu, 19 Dec 2019 at 15:49, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> >
> > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > > > numbers and vice versa. Jakub and I have several whitelist commits
> > > > too, but I think they're all less critical (as mentioned previously,
> > > > most of them are unimportant differences like rtl-optimization vs
> > > > tree-optimization, or debug vs lto, or simply that  the Bugzilla
> > > > component has been changed since the commit was done and the commit
> > > > was actually right at the time).
> > > >
> > >
> > > Merged
> >
> > And I've fixed up some Python syntax there (commas that needed to be
> > colons, between the commit number and the fixup information).
> 
> Thanks.
> 
> I'm afraid it was too mind-numbing to just work through the list from
> bottom to top. Jakub and I found some problems and some that can be
> whitelisted. I submitted another merge request.

Thanks, merged.

If people have done updates to components in Bugzilla and want a fresh 
list generated using fresh Bugzilla data and the updates to component 
aliases, I can readily do that (using the file of commit messages left 
behind from my last conversion run), load on sourceware permitting.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Jonathan Wakely]

On Thu, 19 Dec 2019 at 16:33, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > On Thu, 19 Dec 2019 at 15:49, Joseph Myers <joseph@codesourcery.com> wrote:
> > >
> > > On Thu, 19 Dec 2019, Richard Earnshaw (lists) wrote:
> > >
> > > > > Done. https://gitlab.com/esr/gcc-conversion/merge_requests/25 fixes
> > > > > (most of?) the most egregious ones, like fortran fixes with c++ PR
> > > > > numbers and vice versa. Jakub and I have several whitelist commits
> > > > > too, but I think they're all less critical (as mentioned previously,
> > > > > most of them are unimportant differences like rtl-optimization vs
> > > > > tree-optimization, or debug vs lto, or simply that  the Bugzilla
> > > > > component has been changed since the commit was done and the commit
> > > > > was actually right at the time).
> > > > >
> > > >
> > > > Merged
> > >
> > > And I've fixed up some Python syntax there (commas that needed to be
> > > colons, between the commit number and the fixup information).
> >
> > Thanks.
> >
> > I'm afraid it was too mind-numbing to just work through the list from
> > bottom to top. Jakub and I found some problems and some that can be
> > whitelisted. I submitted another merge request.
>
> Thanks, merged.
>
> If people have done updates to components in Bugzilla and want a fresh
> list generated using fresh Bugzilla data and the updates to component
> aliases, I can readily do that (using the file of commit messages left
> behind from my last conversion run), load on sourceware permitting.

I've updated a tiny handful of bugs (just two IIRC) where the
component was obviously suboptimal.

Jakub and I came up with the following list of suggestions for
component changes:

92324 from c to tree-optimization
91763 from go to lto
91772 from lto to debug
91137 from rtl-optimization to tree-optimization
91445 from c++ to tree-optimization
90577 from middle-end to fortran
90716 from debug to tree-optimization
90273 from debug to tree-optimization
90194 from debug to middle-end
89487 rtl-opt to tree-opt
45869 from c to tree-optimization
45176 from c to middle-end
45605 from c++ to tree-optimization
45838 from libgomp to middle-end
44536 from middle-end to fortran
41921 from c++ to lto
43611 from tree-optimization to c++
47541 from c++ to tree-optimization
47293 from fortran to libquadmath
41094 from c++ to middle-end
40492 from c++ to tree-optimization

Re: Commit messages and the move to git

[Joseph Myers]

On Thu, 19 Dec 2019, Jonathan Wakely wrote:

> Jakub and I came up with the following list of suggestions for
> component changes:

Since we don't normally review changes to individual bugs, if you think 
the new component is better than the old one (is a better representation 
of the subject area of the bug, not just more convenient for bugdb.py) I 
think you should just go ahead and make the change.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Thu, 19 Dec 2019, Jonathan Wakely wrote:

> I've attached an updated list to this mail, which removes the items
> we've analysed. There are 531 remaining.

With the current version of the script (including the various whitelisted 
component pairs discussed) and with data freshly downloaded from Bugzilla 
(but with GCC commit messages from a couple of days ago, I'll do a fresh 
conversion run shortly), I now get a list of 481, attached.

-- 
Joseph S. Myers
joseph@codesourcery.com

[-- Attachment #2: Type: text/plain, Size: 53443 bytes --]

re PR rtl-optimization/13024 (gcj can't build current rhug [checkme: java SVN r73752])
backport: re PR rtl-optimization/12816 (internal compiler error pari-2.1.5/Olinux-i686 [checkme: c++ SVN r75851])
revert: re PR tree-optimization/16115 (double-destruction problem with argument passing via temporary (breaks auto_ptr) [checkme: c++ SVN r84147])
re PR tree-optimization/15262 ([tree-ssa] Alias analyzer cannot handle addressable fields [checkme: c SVN r86398])
re PR rtl-optimization/15857 (Wrong code with optimization >= -O1 [checkme: c++ SVN r87429])
re PR c/16403 (Floating-point assignment to int is inconsistent [checkme: INVALID SVN r94142])
re PR c++/20505 (internal error when compiling with -ggdb2 and no error with -ggdb1 [checkme: debug SVN r97528])
re PR tree-optimization/21562 (Quiet bad codegen (unrolling + tail call interaction) [checkme: c SVN r103245])
re PR c/21419 (Accepts writting to const via asm [checkme: tree-optimization SVN r104991])
re PR awt/26641 (AWT mouse event handling regression [checkme: libgcj SVN r112464])
re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114637])
re PR java/28024 (libjava build failure on Solaris 2.8 (sun4u) [checkme: INVALID SVN r114639])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121666])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121667])
re PR debug/33739 (Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin [checkme: fortran SVN r130244])
re PR c++/31863 (g++-4.1: out of memory with -O1/-O2 [checkme: middle-end SVN r131405])
re PR c/34601 (ICE with undefined enum [checkme: middle-end SVN r131506])
re PR middle-end/34668 (ICE in find_compatible_field with -combine [checkme: c SVN r131572])
re PR tree-optimization/34885 (ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574 [checkme: c SVN r131694])
re PR c++/34953 (ICE on destructor + noreturn-function at -O3 [checkme: middle-end SVN r131782])
re PR translation/35002 (Incorrect spelling of "hottest" [checkme: c SVN r131940])
re PR driver/30330 (-Wdeprecated is not documented [checkme: documentation SVN r132131])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133106])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133108])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133195])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133220])
re PR preprocessor/34866 (valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c [checkme: libcpp SVN r134421])
re PR preprocessor/15500 (gcc ignores locale when converting wide string literals to wchar_t strings [checkme: libcpp SVN r134441])
re PR preprocessor/33415 (Can't compile .cpp file with UTF-8 BOM. [checkme: libcpp SVN r134507])
re PR c++/35652 (offset warning should be given in the front-end [checkme: c SVN r134714])
re PR fortran/36117 (Use MPFR for bessel function (optimization, rejects valid F2008) [checkme: middle-end SVN r135113])
re PR c++/36185 (wrong code with  -O2 -fgcse-sm [checkme: rtl-optimization SVN r135159])
re PR c++/35336 (Broken diagnostic: 'bit_field_ref' not supported by dump_expr [checkme: middle-end SVN r136662])
re PR c++/36460 (No space between >'s not always handled in C++0x [checkme: c SVN r136919])
re PR middle-end/36571 (Default untyped return for AVR is byte register. [checkme: c SVN r136926])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r136989])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r137001])
re PR tree-optimization/34371 (verify_stmts failed (incorrect sharing of tree nodes) [checkme: fortran SVN r137088])
re PR rtl-optimization/36672 (IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829 [checkme: preprocessor SVN r137581])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r137793])
re PR ada/36957 (ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge [checkme: tree-optimization SVN r138217])
re PR ada/15479 (Ada manual problems [checkme: documentation SVN r138293])
re PR middle-end/36633 (warning "array subscript is below array bounds" on delete [] with -O2, -Wall [checkme: c++ SVN r138425])
re PR c++/17880 (-Wsequence-point doesn't warn inside if, while, do conditions, for beg/cond/end expressions etc. [checkme: c SVN r138904])
re PR c++/28152 (Diagnostic about wrong use _Complex prints __complex__ [checkme: c SVN r139097])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r139159])
re PR c++/8895 (ICE on invalid template default value specification [checkme: libgcj SVN r139492])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139784])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139786])
re PR ada/37328 (ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747 [checkme: tree-optimization SVN r139931])
re PR middle-end/18071 (-Winline does not respect -fno-default-inline [checkme: c++ SVN r140418])
re PR debug/37410 (DW_TAG_imported_module is not in its DW_TAG_lexical_block [checkme: c++ SVN r140895])
re PR middle-end/29609 (Even with  -O0 -g gcc optimizes a goto away and I cannot debug [checkme: debug SVN r140948])
re PR tree-optimization/37568 (ICE returning a struct [checkme: c++ SVN r141010])
re PR debug/27017 (Debug information for static local class members are not emitted [checkme: c++ SVN r141829])
re PR debug/27574 (MIssing debug info at -O0 for a local variable in a C++ constructor [checkme: c++ SVN r141984])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142840])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142841])
re PR middle-end/36191 (can't use complex in a eh region if non-call-exceptions is enabled [checkme: c++ SVN r142950])
re PR tree-optimization/38385 (ICE with -O2 -ftree-loop-distribution [checkme: middlend SVN r143291])
re PR c++/38908 (Unexplained "'<anonymous>' is used uninitialized in this function" warning in cc1plus -m64 [checkme: middle-end SVN r143722])
re PR c++/29027 (template conversion specialization found by using declaration [checkme: c SVN r144443])
re PR c++/29027 (template conversion specialization found by using declaration [checkme: c SVN r145422])
re PR c++/8781 (Pessimization of C++ (functional) code [checkme: tree-optimization SVN r145533])
re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145569])
backport: re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145574])
re PR middle-end/39614 (Internal error compiling CSiBE [checkme: c SVN r145737])
re PR rtl-optimization/37377 (Bootstrap failure compiling libgcc [checkme: fortran SVN r145965])
re PR c/39928 (gimplify_expr failure [checkme: middle-end SVN r146846])
re PR java/39940 (failure in jc1 on i686-apple-darwin9 host [checkme: tree-optimization SVN r147065])
re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r147659])
re PR middle-end/39834 (verify_cgraph_node failed with -O3 -Winline [checkme: debug SVN r148292])
backport: re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r148469])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149470])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149499])
re PR c/48388 (libgcc compilation causes a segfault [checkme: middle-end SVN r149516])
re PR middle-end/40867 (FAIL: StackTrace2 output - source compiled test [checkme: java SVN r150376])
re PR debug/40660 (Weird break points with 4.5, works with 4.4 [checkme: fortran SVN r151069])
re PR c/41163 (verify_gimple fails [checkme: middle-end SVN r151122])
re PR c++/41273 (ICE in add_virtual_operand, at tree-ssa-operands.c:638 [checkme: debug SVN r151454])
re PR c++/41144 (ice for legal code with -O2 in get_alias_set [checkme: middle-end SVN r151461])
re PR c/39779 (ICE shifting byte to the right with constant > 7FFFFFFF [checkme: rtl-optimization SVN r151573])
re PR c++/41275 (ICE: expand_expr_real_1, at expr.c:8416 [checkme: middle-end SVN r151631])
re PR c/41935 (ICE : tree check: expected integer_cst, have nop_expr in int_cst_value, at tree.c:8301 [checkme: middle-end SVN r153962])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154061])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154063])
re PR c++/26965 (Unnecessary debug info for unused consts in C++ [checkme: debug SVN r154157])
re PR c++/41961 (Internal error with -O3 and -ftree-parallelize-loops [checkme: tree-optimization SVN r154748])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154878])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154879])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154885])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154965])
re PR libstdc++/42381 (deque shouldn't reserve that much memory [checkme: libsdtc++ SVN r155271])
re PR tree-optimization/42386 (ICE in ipcp_iterate_stage, at ipa-cp.c:766 [checkme: c++ SVN r155321])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r155765])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156010])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156016])
re PR debug/42991 (cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s) [checkme: middle-end SVN r156575])
re PR c/43125 (Revision 156907 failed gcc.dg/attr-used.c [checkme: middle-end SVN r156927])
re PR rtl-optimization/43058 (var-tracking uses up all virtual memory [checkme: debug SVN r157547])
re PR c/43661 (ice in fold_comparison, at fold-const.c:9579 [checkme: middle-end SVN r157984])
re PR debug/42425 (ICE declaring local class [checkme: lto SVN r158722])
re PR c++/43080 (ICE with anonymous union and -flto [checkme: lto SVN r158723])
re PR c++/40561 (code does not compile -- compiles fine when replacing != with !(==) [checkme: middle-end SVN r158778])
re PR c/44024 (missed optimization [checkme: middle-end SVN r159205])
re PR middle-end/44104 (New test failures [checkme: debug SVN r159367])
re PR c++/44256 (When using -flto and -fwhole-program the compiler/linker crash [checkme: lto SVN r159779])
re PR lto/44248 (-fcompare-debug failure with -flto/-fwhopr -g [checkme: debug SVN r161056])
backport: re PR middle-end/44104 (New test failures [checkme: debug SVN r161666])
re PR fortran/44882 (Bogus types in references with mismatched commons [checkme: tree-optimization SVN r161990])
re PR debug/44689 (-fenable-icf-debug causes segfault in cp_function_decl_explicit_p [checkme: fortran SVN r162052])
re PR c++/36960 (Reference variable in virtually inherited base corrupted under optimization [checkme: tree-optimization SVN r162141])
re PR c++/45382 (internal compiler error: tree code ‘call_expr’ is not supported in gimple streams [checkme: lto SVN r165471])
re PR tree-optimization/20165 (Pointer does not really escape with write [checkme: fortran SVN r165559])
re PR rtl-optimization/45834 (Redundant inter-loop edges in DDG [checkme: c SVN r165781])
re PR c++/46134 (constexpr vs. defaulted ctor [checkme: INVALID SVN r166171])
re PR debug/46241 (ice in dwarf2out.c [checkme: middle-end SVN r166245])
re PR rtl-optimization/33172 (Optimizer fails to elid away unreferenced static function [checkme: tree-optimize SVN r166557])
re PR fortran/38669 (Array bounds violation for arguments of elemental subroutine [checkme: tree-optimize SVN r166579])
re PR rtl-optimization/42889 ("-fcompare-debug failure (length)" with "-O1 -fgcse" [checkme: debug SVN r166719])
re PR middle-end/46297 (gfortran.dg/g77/980701-0.f FAILs with -Os -fno-asynchronous-unwind-tables [checkme: middle-end-optimization SVN r166905])
re PR driver/44986 (-fuse-linker-plugin -save-temps gives resolution file base name of last argument [checkme: lto SVN r167292])
re PR c++/44871 (Invalid type mismatches while merging C and C++ sources [checkme: lto SVN r167367])
re PR middle-end/46745 ('#'mem_ref' not supported by dump_expr#<expression error>' [checkme: c SVN r167433])
re PR driver/46760 (LTO bootstrap doesn't work with FDO [checkme: tree-optimization SVN r167458])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r167487])
re PR lto/46576 (BFD linker plugin generates bad executables [checkme: debug SVN r167738])
re PR middle-end/46885 (ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:251 with -ftree-parallelize-loops -g [checkme: debug SVN r167801])
re PR tree-optimization/46469 (ICE: verify_cgraph_node failed: inline clone is needed at -O [checkme: tree-optmization SVN r168598])
re PR c/32511 (GCC rejects inline+weak function [checkme: middle-end SVN r168652])
re PR tree-optimization/46583 (-fcompare-debug failure with -O -fno-inline -fipa-cp -fipa-cp-clone [checkme: debug SVN r169058])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169310])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169377])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169634])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169677])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r169851])
re PR debug/47647 (BLOCKs are empty [checkme: lto SVN r170321])
re PR debug/47283 (ICE in refs_may_alias_p_1, at tree-ssa-alias.c [checkme: middle-end SVN r170650])
re PR c++/48073 (ICE with -flto in templated C++ code [checkme: lto SVN r170875])
re PR c++/13954 ([tree-ssa] SRA does not work for classes that use inheritance with an empty base [checkme: tree-optimization SVN r170994])
re PR driver/46944 (gcc should accept -fuse-linker-plugin only if linker handles -plugin [checkme: lto SVN r171039])
re PR c/48146 (ICE tree check: expected ssa_name, have var_decl in has_zero_uses, at tree-flow-inline.h:342 [checkme: tree-optimization SVN r171045])
re PR c/48650 (valgrind: Invalid write of size 8 in build_string (tree.c:1524) [checkme: middle-end SVN r172642])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172649])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172650])
re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172706])
re PR debug/48207 (ICE in lhd_set_decl_assembler_name, at langhooks.c:158 [checkme: lto SVN r172708])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172765])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172766])
re PR c/47892 (Fails to vectorize comparison code, if-conversion fails [checkme: tree-optimization SVN r172774])
re PR debug/48703 (segfault in canonicalize_for_substitution [checkme: lto SVN r172830])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172963])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172964])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173876])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173877])
re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r173901])
backport: re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r174476])
re PR java/23754 (tree check error in check_inner_circular_reference [checkme: lto SVN r175174])
re PR middle-end/49373 (Many testcase failures [checkme: tree-optimize SVN r175336])
re PR rtl-optimization/49686 (CFI notes are missed for delayed slot [checkme: debug SVN r176091])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176448])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176481])
re PR tree-optimization/49957 (Fails to SLP in 410.bwaves [checkme: fortran SVN r177368])
re PR middle-end/37221 (Missed early loop-unroll optimization - causes 40% degradation on SPU [checkme: fortran SVN r177486])
re PR debug/50006 (ICE in in connect_traces, at dwarf2cfi.c:2677 [checkme: middle-end SVN r177764])
re PR rtl-optimization/50191 (Strange debug insn produced for TOC compiling 416.gamess with profile-generate [checkme: debug SVN r178625])
re PR libgomp/50386 (libgomp.h:87:5: error: unnamed struct/union that defines no instances [checkme: middle-end SVN r179285])
re PR c/50507 (Huge amount of memory used while building GCC4 [checkme: c++ SVN r180002])
re PR middle-end/49310 (Compile time hog in var-tracking emit [checkme: debug SVN r180194])
re PR driver/41844 (lto1: warning: unknown register name: line-length-none [checkme: lto SVN r180517])
re PR debug/51262 (ICE: SIGSEGV in primary_template_instantiation_p (pt.c:2874) with -flto -g [checkme: lto SVN r182221])
re PR debug/48354 (internal compiler error: in splice_child_die, at dwarf2out.c:8064 [checkme: lto SVN r182286])
re PR debug/51564 (ICE in force_type_die, at dwarf2out.c:19288 [checkme: lto SVN r182367])
re PR debug/51567 (ICE in splice_child_die, at dwarf2out.c:5009 with -flto -g [checkme: lto SVN r182377])
re PR tree-optimization/51557 (ICE: in maybe_record_trace_start, at dwarf2cfi.c:2244 with custom flags [checkme: debug SVN r182404])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r182524])
re PR debug/51650 (LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul [checkme: lto SVN r182625])
re PR c/51730 (autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7 [checkme: middle-end SVN r182830])
re PR c/8081 (ICE with variably sized types returned from nested functions [checkme: middle-end SVN r183153])
re PR c++/53207 (bool conversion on return [checkme: tree-optimization SVN r184623])
re PR c++/52582 (g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit) [checkme: middle-end SVN r185381])
re PR c++/52772 (internal compiler error: Segmentation fault [checkme: middle-end SVN r186011])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186494])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186593])
re PR c++/53050 (ssa_forward_propagate_and_combine: segmentation fault [checkme: tree-optimization SVN r186620])
re PR c/11586 (after call sigaction, system() return wrong status [checkme: INVALID SVN r187542])
re PR rtl-optimization/53373 (ICE on valid code with -mavx [checkme: rtl-optimzation SVN r187695])
re PR fortran/53148 (Incorrect intrinsic function parsing on labeled statements when compiled w/ -ffrontend-optimize [checkme: c SVN r187718])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187931])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187932])
re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188298])
re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188386])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188387])
backport: re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188615])
backport: re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188625])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188811])
re PR rtl-optimization/53706 (Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418) [checkme: debug SVN r189037])
re PR c/53937 (Pack'ing struct causes gcc to not recognize that an field's address is aligned [checkme: middle-end SVN r189458])
re PR web/53919 (Version-specific install instructions not available [checkme: c++ SVN r189545])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190533])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190534])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r191066])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191614])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191615])
re PR middle-end/53024 (Support vector_size that is not a power of 2 [checkme: c SVN r191800])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192119])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192121])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192122])
re PR lto/54980 (gimple check: expected gimple_cond(error_mark), have gimple_call() in gimple_cond_set_lhs, at gimple.h:2578 [checkme: tree-optimize SVN r192809])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193331])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193406])
re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r193649])
re PR rtl-optimization/55717 (ICE in form_sum, at reload.c:5400 [checkme: debug SVN r194575])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r194680])
re PR tree-optimization/55875 (IVopts caused miscompilation [checkme: tree-optimiation SVN r195054])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r195173])
re PR libstdc++/51083 (TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained [checkme: tree-optimizatoin SVN r195274])
re PR rtl-optimization/55273 (ICE in iv_number_of_iterations, at loop-iv.c:2819 [checkme: tree-optimizatoin SVN r195275])
re PR libffi/56000 (FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test [checkme: middle-end SVN r195277])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195541])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195542])
re PR debug/54410 (doubled DW_TAG_template_type_param [checkme: c++ SVN r195613])
re PR sanitizer/55561 (TSAN: provide a TSAN instrumented libgomp [checkme: libgomp SVN r195618])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r195632])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195646])
backport: re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r195650])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195707])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195751])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195758])
re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r195796])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195844])
re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196133])
backport: re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r196141])
backport: re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196149])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r196769])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197047])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197048])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197201])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197203])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197349])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197350])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197351])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197420])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197421])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197454])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198445])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198446])
re PR c++/57038 (Latest libreoffice compilation fails with enabled LTO [checkme: lto SVN r198917])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199282])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199283])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199284])
re PR c++/57208 (Latest chromium compilation fails with enabled LTO [checkme: lto SVN r200468])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201696])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201697])
re PR c++/58201 (Undefined reference to `B::B(void const**)' [checkme: middle-end SVN r202298])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202496])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202498])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202564])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202565])
re PR c/20318 (RFE: add attribute to specify that a function never returns NULL [checkme: tree-optimization SVN r203316])
re PR c/52862 (ICE convert_to_pointer, at convert.c:50 [checkme: plugin SVN r204650])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205481])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205487])
backport: re PR target/59405 (Incorrect FP<->MMX transition during call/ret [checkme: INVALID SVN r205790])
re PR middle-end/59399 (ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow [checkme: sanitizer SVN r205888])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205991])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205993])
re PR fortran/45586 (ICE non-trivial conversion at assignment [checkme: lto SVN r206461])
re PR c++/58252 (ice in gimple_get_virt_method_for_binfo with -O2 [checkme: ipa SVN r206516])
re PR fortran/59706 (ICE with do concurrent and internal subprogram [checkme: middle-end SVN r206732])
re PR ipa/59469 (LLVM build failure with gcc LTO [checkme: c++ SVN r207366])
re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r207695])
re PR fortran/60060 (lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096 [checkme: lto SVN r207715])
backport: re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r208366])
re PR c++/60474 (Crash in tree_class_check [checkme: middle-end SVN r208451])
re PR c++/60553 (segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO [checkme: middle-end SVN r208682])
re PR c++/60750 (double free after std::move on string inside throw when compiled with optimization [checkme: middle-end SVN r209179])
re PR libfortran/60706 (FAIL: gfortran.dg/size_kind_2.f90  -O   scan-tree-dump original "var2 = 42949673 00;" [checkme: middle-end SVN r209216])
re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209468])
backport: re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209630])
re PR debug/61070 (debug_bitmap writes to stdout [checkme: middle-end SVN r210098])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210181])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210203])
re PR c/61136 (ice in tree_nop_conversion [checkme: tree-optimization SVN r210312])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210426])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210472])
re PR c++/60189 (ICE with invalid use of _Cilk_sync [checkme: c SVN r210678])
re PR c++/60189 (ICE with invalid use of _Cilk_sync [checkme: c SVN r210680])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212174])
re PR middle-end/60226 (ICE initializing array of elements with too large alignment [checkme: c SVN r212346])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212436])
re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212521])
backport: re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212741])
re PR ipa/61921 (ICE: SIGSEGV in varpool_node::get_constructor(), at varpool.c:275 with -O2 -fipa-pta [checkme: tree-optimization SVN r213114])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r213308])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213491])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213492])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213812])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213901])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213904])
re PR preprocessor/60975 (-Wvariadic-macros does not print warning [checkme: c SVN r214200])
re PR c++/62175 (Internal compiler error in gimplify_modify_expr gimplify.c:4616 [checkme: tree-optimization SVN r214492])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214543])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214546])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r214678])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r215134])
re PR c++/63419 (verify_gimple failed: "vector CONSTRUCTOR element is not a GIMPLE value" [checkme: tree-optimization SVN r216138])
re PR c++/62127 (ICE with VLA in constructor [checkme: tree-optimization SVN r216150])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r216273])
re PR c/63554 (ice in "execute_todo, at passes.c:1797" with -O3 [checkme: middle-end SVN r216315])
re PR middle-end/63879 (ICE compiling Linux Kernel fs/ext3/namei.c with -fsanitize=undefined [checkme: sanitizer SVN r217766])
re PR tree-optimization/64004 ([5 Regressio] Build error in tree-ssa-loop-niter.c in maybe_lower_iteration_bound [checkme: java SVN r218018])
re PR tree-optimization/64121 (ICE: SSA corruption with -O -fsanitize=undefined [checkme: sanitizer SVN r218222])
re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220152])
re PR sanitizer/64717 (-fsanitize=vptr leads to warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized] [checkme: c++ SVN r220262])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220327])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220335])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220420])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220617])
backport: re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220622])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220624])
re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r221776])
re PR c++/65626 (ICE in fixup_noreturn_call called by tree-ssa-forwprop.c:2492 [checkme: middle-end SVN r221790])
re PR middle-end/65554 (ICE: verify_gimple failed [checkme: c++ SVN r221808])
re PR c++/65851 (ice in set_lattice_value at tree-ssa-cc p.c:535 [checkme: tree-optimization SVN r222510])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222514])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222843])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222849])
re PR ipa/65701 (r221530 makes 187.facerec drop with -Ofast -flto on bdver2 [checkme: tree-optimization SVN r223528])
backport: re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r224090])
re PR debug/66503 (missing DW_AT_abstract_origin for cross-unit call sites [checkme: middle-end SVN r224372])
re PR rtl-optimization/66351 (r223883 miscompiles stage2 compiler on ia64 [checkme: ipa SVN r224719])
re PR preprocessor/53690 ([C++11] \u0000 and \U00000000 are wrongly encoded as U+0001. [checkme: c++ SVN r225353])
re PR ipa/66793 (ICE at -Os and above on x86_64-linux-gnu (verify_flow_info failed) [checkme: tree-optimization SVN r225546])
re PR lto/66468 (ICE in in check_die, at dwarf2out.c:5719 [checkme: debug SVN r226255])
re PR c/67107 (ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations [checkme: middle-end SVN r226609])
re PR c/67279 (-fsanitize=undefined spurious error: initializer element is not constant [checkme: sanitizer SVN r227491])
re PR c/48885 (missed optimization with restrict qualifier? [checkme: tree-optimization SVN r228073])
re PR fortran/67170 (PRE can't hoist out a readonly argument [checkme: tree-optimization SVN r228244])
re PR c/67882 (surprising offsetof result on an invalid array member without diagnostic [checkme: c++-common SVN r229717])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230897])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230901])
re PR c++/67581 (ICE on transparent union with -g enabled on x86_64-linux-gnu (verify_type failed) [checkme: c SVN r231048])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231100])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231110])
re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231217])
re PR middle-end/68656 (warning about disabled var-tracking uses odd location info [checkme: c SVN r231292])
backport: re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231677])
re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r232122])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232169])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232171])
re PR tree-optimization/69164 (ICE in create_tmp_var, at gimple-expr.c:468 [checkme: c++ SVN r232187])
re PR debug/69077 (omnetpp ICEs with -flto -g [checkme: lto SVN r232272])
re PR c++/66487 (sanitizer/warnings for lifetime DSE [checkme: ipa SVN r232356])
re PR tree-optimization/69355 (Wrong results with -O1 optimization [checkme: c++ SVN r232663])
re PR c++/69267 ([cilkplus] ICE when calling a function with an empty class as an argument [checkme: cilkplus SVN r232887])
re PR middle-end/69643 (Address space discarded [checkme: c SVN r233189])
re PR middle-end/69537 (Incorrect -Wmaybe-uninitialized warning with enum variable [checkme: go SVN r233235])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233288])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233327])
re PR tree-optimization/69110 (execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2 [checkme: fortran SVN r233782])
re PR middle-end/70054 (GCC 6 gives a strict-aliasing warning on use of std::aligned_storage [checkme: c++ SVN r233961])
re PR sanitizer/70135 (-fsanitize=undefined causes static_assert to fail [checkme: c++ SVN r234064])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234248])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234249])
re PR tree-optimization/70144 (g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref" [checkme: c++ SVN r234297])
re PR middle-end/70280 (-fcompare-debug failure (length) with --param=integer-share-limit=4016 -mavx512bw [checkme: c SVN r234312])
re PR middle-end/70273 (FAIL: g++.dg/ext/label13a.C  -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev [checkme: c++ SVN r234386])
re PR preprocessor/69650 (ICE in linemap_line_start, at libcpp/line-map.c:803 [checkme: lto SVN r234481])
re PR middle-end/70307 (ICE: in gimplify_expr, at gimplify.c:10915 on valid code [checkme: c SVN r234706])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235063])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235065])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235081])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235318])
re PR go/49889 (Calling a function whose name is obscured by a local variable does not produce an error [checkme: middle-end SVN r235484])
re PR fortran/70931 (ICE with -g in native_encode_initializer, bei dwarf2out.c:17768 [checkme: middle-end SVN r235944])
re PR ada/70786 (Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available) [checkme: tree-optimization SVN r236086])
re PR middle-end/71249 (-Wswitch-unreachable false positive for a compound statement containing a used label [checkme: c SVN r236649])
re PR c++/61564 (#pragma GCC optimize ("-fno-lto") causes the compiler to crash [checkme: c SVN r237174])
re PR middle-end/50060 (intrinsics not folded by the middle-end [checkme: c++ SVN r238520])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238579])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238580])
re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239855])
re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239904])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239930])
backport: re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239933])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240006])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240025])
re PR rtl-optimization/64316 (ICE in simplify_const_unary_operation after r218503 [checkme: ipa SVN r240081])
re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r240348])
re PR fortran/77678 (ICE in fold_read_from_constant_string, at fold-const.c:13706 [checkme: middle-end SVN r240351])
re PR rtl-optimization/77714 (Wrong code generation for gcc.c-torture/execute/pr51447.c [checkme: rlt-optimization SVN r240518])
re PR c++/78051 (error: dead STMT in EH table when using -O2 [checkme: tree-optimization SVN r241394])
re PR tree-optimization/35503 (Warning about restricted pointers? [checkme: c SVN r242366])
re PR tree-optimization/66419 (FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution,  -O3 -g [checkme: debug SVN r243126])
re PR tree-optimization/78692 (ICE (segfault) [checkme: c++ SVN r243377])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r243387])
re PR middle-end/78622 (-Wformat-length/-fprintf-return-value incorrect with overflow/wrapping [checkme: fortran SVN r243765])
re PR middle-end/79089 (error: incorrect sharing of tree nodes [checkme: c SVN r244507])
backport: re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r244870])
re PR c++/79129 (ICE with -fdebug-types-section starting with r240578 [checkme: debug SVN r244955])
re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245053])
re PR tree-optimization/79347 (vect_do_peeling is messing up profile [checkme: tree-ssa SVN r245196])
re PR middle-end/56727 (Recursive call goes through the PLT unnecessarily [checkme: tree-ssa SVN r245359])
backport: re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245466])
re PR inline-asm/79552 (Wrong code generation due to -fschedule-insns, with __restrict__ and inline asm [checkme: tree-optimization SVN r245528])
re PR rtl-optimization/79286 (ira and lra wrong code at -O2 and -Os on i686-linux [checkme: rtl-optimizatoin SVN r245714])
re PR c/79731 (ICE: verify_gimple failed [checkme: middle-end SVN r245779])
re PR middle-end/79756 (ICE in execute_todo, at passes.c:2011 [checkme: c SVN r245838])
re PR fortran/79894 (ICE in gfc_add_modify_loc, at fortran/trans.c:159 [checkme: tree-optimization SVN r245923])
re PR c++/80075 (ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions [checkme: middle-end SVN r246223])
re PR middle-end/67338 (fold-const sanitizer runtime error  in roundup_loc [checkme: c SVN r246305])
re PR ipa/78644 (ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp [checkme: tree-optimization SVN r246534])
re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r246621])
re PR middle-end/80163 (ICE on hopefully valid code [checkme: c SVN r246876])
re PR c++/69953 (Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail [checkme: lto SVN r246899])
re PR fortran/80494 (ICE in wide_int_to_tree [checkme: tree-optimization SVN r247095])
backport: re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r247694])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r248602])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r248612])
re PR sanitizer/81065 (UBSAN: false positive as a result of distribution involving different types [checkme: middle-end SVN r249144])
re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249174])
re PR sanitizer/81097 (UBSAN: false positive for not existing negation operator and a bogus message [checkme: middle-end SVN r249407])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249479])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249510])
re PR sanitizer/81505 (ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow [checkme: middle-end SVN r250494])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r250853])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r251143])
re PR c++/82054 (ICE in add_dwarf_attr with -fopenmp and -g [checkme: middle-end SVN r251559])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251661])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251711])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r252277])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r252458])
re PR debug/82144 (ICE in add_dwarf_attr with alignas [checkme: middle-end SVN r253134])
re PR c/82765 (ICE at -Os on valid code on x86_64-linux-gnu: in tree_to_shwi, at tree.c:6611 [checkme: middle-end SVN r254337])
re PR fortran/83017 (DO CONCURRENT not parallelizing [checkme: tree-optimization SVN r254867])
re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255354])
re PR middle-end/83415 (ICE during gimplification of assignment to read-only vector [checkme: c SVN r255629])
re PR sanitizer/83388 (reference statement index not found error with -fsanitize=null [checkme: lto SVN r255694])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255722])
re PR ipa/81877 (Incorrect results with lto and -fipa-cp and -fipa-cp-clone [checkme: tree-optimization SVN r255776])
re PR c++/83482 (internal compiler error: Segmentation fault [checkme: tree-optimization SVN r255817])
re PR debug/83694 (New test case gcc.dg/pr83666.c from r256232 ICEs [checkme: middle-end SVN r256307])
re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256341])
re PR rtl-optimization/81308 (ICE in calc_dfs_tree, at dominance.c:458 [checkme: rtl-optimizatin SVN r256349])
re PR c++/80763 (-O3 causes error: inline clone in same comdat group list [checkme: ipa SVN r256369])
backport: re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256371])
re PR c++/86620 (__attribute__((no inline)) gives incorrect warning with overloaded functions [checkme: rtl-optimization SVN r256729])
re PR fortran/84000 (ICE in replace_loop_annotate, at tree-cfg.c:352 [checkme: middle-end SVN r257011])
re PR libgomp/84086 ([8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1 [checkme: tree-optimization SVN r257152])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257721])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257722])
re PR libgomp/84466 (libgomp.graphite/force-parallel-8.c fails starting with r257723 [checkme: tree-optimization SVN r258035])
re PR c/84607 (Side effects discarded in address computation inside 'if' [checkme: middle-end SVN r258061])
re PR debug/85176 (ICE in force_decl_die, at dwarf2out.c:25910 [checkme: lto SVN r259080])
re PR rtl-optimization/85302 (ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu [checkme: debug SVN r259311])
re PR c/86046 (ICE in execute_todo, at passes.c:2043 [checkme: tree-optimization SVN r261193])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r262042])
re PR debug/86523 (ICE in gen_member_die, at dwarf2out.c:24933 starting from r262560 [checkme: lto SVN r262696])
re PR debug/86456 (Segfault in switch_to_section at  gcc/varasm.c:7353 since r259317 [checkme: lto SVN r262819])
re PR lto/86654 (ICE in gen_member_die, at dwarf2out.c:24933 [checkme: debug SVN r262965])
re PR c++/78655 (gcc doesn't exploit the fact that the result of pointer addition can not be nullptr [checkme: tree-optimization SVN r263662])
re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r263967])
backport: re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r264107])
re PR middle-end/41453 (use INTENT(out) for optimization [checkme: fortran SVN r264506])
re PR c/87682 (gcc/mem-stats.h:172: possible broken comparison operator ? [checkme: middle-end SVN r265376])
re PR c++/87469 (ice in record_estimate, at tree-ssa-loop-niter.c:3271 [checkme: middle-end SVN r265605])
re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r265776])
re PR c/87953 (asan: stack-buffer-overflow in vectorizable_reduction [checkme: tree-optimization SVN r265964])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266014])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266015])
re PR target/86677 (popcount builtin detection is breaking some kernel build [checkme: INVALID SVN r266039])
re PR c++/87229 (ICE: tree code 'call_expr' is not supported in LTO streams [checkme: lto SVN r266372])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266550])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266553])
re PR tree-optimization/88367 (-fno-delete-null-pointer-checks doesn't work properly [checkme: c SVN r266878])
re PR c/87944 (Wrong code with LRA pushing stack local variable [checkme: fortran SVN r267184])
re PR tree-optimization/88606 (ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR) [checkme: c SVN r268540])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268748])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268750])
re PR lto/89514 (-g -fdebug-types-section -flto gives 'Dwarf Error: bad length' in gdb [checkme: debug SVN r269250])

Re: Commit messages and the move to git

[Jonathan Wakely]

On Fri, 20 Dec 2019 at 20:30, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Thu, 19 Dec 2019, Jonathan Wakely wrote:
>
> > I've attached an updated list to this mail, which removes the items
> > we've analysed. There are 531 remaining.
>
> With the current version of the script (including the various whitelisted
> component pairs discussed) and with data freshly downloaded from Bugzilla
> (but with GCC commit messages from a couple of days ago, I'll do a fresh
> conversion run shortly), I now get a list of 481, attached.

Should "libcpp" be a compalias of "preprocessor"?

re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp
SVN r133195])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp
SVN r133220])
re PR preprocessor/34866 (valgrind error indication in testsuite from
errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c [checkme: libcpp
SVN r134421])
re PR preprocessor/15500 (gcc ignores locale when converting wide
string literals to wchar_t strings [checkme: libcpp SVN r134441])
re PR preprocessor/33415 (Can't compile .cpp file with UTF-8 BOM.
[checkme: libcpp SVN r134507])

Re: Commit messages and the move to git

[Joseph Myers]

On Fri, 20 Dec 2019, Jonathan Wakely wrote:

> On Fri, 20 Dec 2019 at 20:30, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> >
> > > I've attached an updated list to this mail, which removes the items
> > > we've analysed. There are 531 remaining.
> >
> > With the current version of the script (including the various whitelisted
> > component pairs discussed) and with data freshly downloaded from Bugzilla
> > (but with GCC commit messages from a couple of days ago, I'll do a fresh
> > conversion run shortly), I now get a list of 481, attached.
> 
> Should "libcpp" be a compalias of "preprocessor"?
> 
> re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp
> SVN r133195])
> re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp
> SVN r133220])
> re PR preprocessor/34866 (valgrind error indication in testsuite from
> errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c [checkme: libcpp
> SVN r134421])
> re PR preprocessor/15500 (gcc ignores locale when converting wide
> string literals to wchar_t strings [checkme: libcpp SVN r134441])
> re PR preprocessor/33415 (Can't compile .cpp file with UTF-8 BOM.
> [checkme: libcpp SVN r134507])

Added that alias, thanks.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

On Fri, 20 Dec 2019 at 21:41, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Fri, 20 Dec 2019, Jonathan Wakely wrote:
>
> > On Fri, 20 Dec 2019 at 20:30, Joseph Myers <joseph@codesourcery.com> wrote:
> > >
> > > On Thu, 19 Dec 2019, Jonathan Wakely wrote:
> > >
> > > > I've attached an updated list to this mail, which removes the items
> > > > we've analysed. There are 531 remaining.
> > >
> > > With the current version of the script (including the various whitelisted
> > > component pairs discussed) and with data freshly downloaded from Bugzilla
> > > (but with GCC commit messages from a couple of days ago, I'll do a fresh
> > > conversion run shortly), I now get a list of 481, attached.
> >
> > Should "libcpp" be a compalias of "preprocessor"?
> >
> > re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp
> > SVN r133195])
> > re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp
> > SVN r133220])
> > re PR preprocessor/34866 (valgrind error indication in testsuite from
> > errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c [checkme: libcpp
> > SVN r134421])
> > re PR preprocessor/15500 (gcc ignores locale when converting wide
> > string literals to wchar_t strings [checkme: libcpp SVN r134441])
> > re PR preprocessor/33415 (Can't compile .cpp file with UTF-8 BOM.
> > [checkme: libcpp SVN r134507])
>
> Added that alias, thanks.

I've sent another pull request fixing another 20. Here is the list
with those 20 removed (and this still includes the libcpp vs
preprocessor ones that will be handled by the new alias).

[-- Attachment #2: tocheck.txt --]
[-- Type: text/plain, Size: 51518 bytes --]

re PR rtl-optimization/13024 (gcj can't build current rhug [checkme: java SVN r73752])
backport: re PR rtl-optimization/12816 (internal compiler error pari-2.1.5/Olinux-i686 [checkme: c++ SVN r75851])
revert: re PR tree-optimization/16115 (double-destruction problem with argument passing via temporary (breaks auto_ptr) [checkme: c++ SVN r84147])
re PR tree-optimization/15262 ([tree-ssa] Alias analyzer cannot handle addressable fields [checkme: c SVN r86398])
re PR rtl-optimization/15857 (Wrong code with optimization >= -O1 [checkme: c++ SVN r87429])
re PR c++/20505 (internal error when compiling with -ggdb2 and no error with -ggdb1 [checkme: debug SVN r97528])
re PR tree-optimization/21562 (Quiet bad codegen (unrolling + tail call interaction) [checkme: c SVN r103245])
re PR awt/26641 (AWT mouse event handling regression [checkme: libgcj SVN r112464])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121666])
re PR driver/30714 (gcj driver doesn't recognize files starting with II [checkme: java SVN r121667])
re PR debug/33739 (Failure of gfortran.dg/literal_character_constant_1_*.F with -m64 -g on Darwin [checkme: fortran SVN r130244])
re PR c++/31863 (g++-4.1: out of memory with -O1/-O2 [checkme: middle-end SVN r131405])
re PR c/34601 (ICE with undefined enum [checkme: middle-end SVN r131506])
re PR middle-end/34668 (ICE in find_compatible_field with -combine [checkme: c SVN r131572])
re PR tree-optimization/34885 (ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574 [checkme: c SVN r131694])
re PR c++/34953 (ICE on destructor + noreturn-function at -O3 [checkme: middle-end SVN r131782])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133106])
re PR c/35526 (ICE on memcpy [checkme: middle-end SVN r133108])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133195])
re PR preprocessor/35322 (ICE with incomplete macro [checkme: libcpp SVN r133220])
re PR preprocessor/34866 (valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c [checkme: libcpp SVN r134421])
re PR preprocessor/15500 (gcc ignores locale when converting wide string literals to wchar_t strings [checkme: libcpp SVN r134441])
re PR preprocessor/33415 (Can't compile .cpp file with UTF-8 BOM. [checkme: libcpp SVN r134507])
re PR fortran/36117 (Use MPFR for bessel function (optimization, rejects valid F2008) [checkme: middle-end SVN r135113])
re PR c++/36185 (wrong code with  -O2 -fgcse-sm [checkme: rtl-optimization SVN r135159])
re PR c++/35336 (Broken diagnostic: 'bit_field_ref' not supported by dump_expr [checkme: middle-end SVN r136662])
re PR middle-end/36571 (Default untyped return for AVR is byte register. [checkme: c SVN r136926])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r136989])
re PR debug/34908 (valgrind error indication from testsuite hashtab.c : htab_hash_string [checkme: fortran SVN r137001])
re PR tree-optimization/34371 (verify_stmts failed (incorrect sharing of tree nodes) [checkme: fortran SVN r137088])
re PR rtl-optimization/36672 (IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829 [checkme: preprocessor SVN r137581])
re PR ada/36957 (ACATS ce3801b ICE emit_move_insn, at expr.c:3381 post tuple merge [checkme: tree-optimization SVN r138217])
re PR middle-end/36633 (warning "array subscript is below array bounds" on delete [] with -O2, -Wall [checkme: c++ SVN r138425])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r139159])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139784])
re PR middle-end/37261 (Spurious (?) "integer overflow in expression" warnings [checkme: c SVN r139786])
re PR ada/37328 (ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747 [checkme: tree-optimization SVN r139931])
re PR middle-end/18071 (-Winline does not respect -fno-default-inline [checkme: c++ SVN r140418])
re PR debug/37410 (DW_TAG_imported_module is not in its DW_TAG_lexical_block [checkme: c++ SVN r140895])
re PR middle-end/29609 (Even with  -O0 -g gcc optimizes a goto away and I cannot debug [checkme: debug SVN r140948])
re PR tree-optimization/37568 (ICE returning a struct [checkme: c++ SVN r141010])
re PR debug/27017 (Debug information for static local class members are not emitted [checkme: c++ SVN r141829])
re PR debug/27574 (MIssing debug info at -O0 for a local variable in a C++ constructor [checkme: c++ SVN r141984])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142840])
revert: re PR libfortran/24685 (real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90) [checkme: INVALID SVN r142841])
re PR middle-end/36191 (can't use complex in a eh region if non-call-exceptions is enabled [checkme: c++ SVN r142950])
re PR tree-optimization/38385 (ICE with -O2 -ftree-loop-distribution [checkme: middlend SVN r143291])
re PR c++/38908 (Unexplained "'<anonymous>' is used uninitialized in this function" warning in cc1plus -m64 [checkme: middle-end SVN r143722])
re PR c++/8781 (Pessimization of C++ (functional) code [checkme: tree-optimization SVN r145533])
re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145569])
backport: re PR c/39648 (internal compiler error: in fold_convert, at fold-const.c:2506 [checkme: tree-optimization SVN r145574])
re PR middle-end/39614 (Internal error compiling CSiBE [checkme: c SVN r145737])
re PR rtl-optimization/37377 (Bootstrap failure compiling libgcc [checkme: fortran SVN r145965])
re PR c/39928 (gimplify_expr failure [checkme: middle-end SVN r146846])
re PR java/39940 (failure in jc1 on i686-apple-darwin9 host [checkme: tree-optimization SVN r147065])
re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r147659])
re PR middle-end/39834 (verify_cgraph_node failed with -O3 -Winline [checkme: debug SVN r148292])
backport: re PR tree-optimization/40168 (finding common subexpressions [checkme: fortran SVN r148469])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149470])
re PR middle-end/40502 (crash in cp_diagnostic_starter [checkme: c++ SVN r149499])
re PR c/48388 (libgcc compilation causes a segfault [checkme: middle-end SVN r149516])
re PR middle-end/40867 (FAIL: StackTrace2 output - source compiled test [checkme: java SVN r150376])
re PR debug/40660 (Weird break points with 4.5, works with 4.4 [checkme: fortran SVN r151069])
re PR c/41163 (verify_gimple fails [checkme: middle-end SVN r151122])
re PR c++/41273 (ICE in add_virtual_operand, at tree-ssa-operands.c:638 [checkme: debug SVN r151454])
re PR c++/41144 (ice for legal code with -O2 in get_alias_set [checkme: middle-end SVN r151461])
re PR c/39779 (ICE shifting byte to the right with constant > 7FFFFFFF [checkme: rtl-optimization SVN r151573])
re PR c++/41275 (ICE: expand_expr_real_1, at expr.c:8416 [checkme: middle-end SVN r151631])
re PR c/41935 (ICE : tree check: expected integer_cst, have nop_expr in int_cst_value, at tree.c:8301 [checkme: middle-end SVN r153962])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154061])
re PR middle-end/20548 (ACATS c52103x c52104x c52104y segfault [checkme: ada SVN r154063])
re PR c++/26965 (Unnecessary debug info for unused consts in C++ [checkme: debug SVN r154157])
re PR c++/41961 (Internal error with -O3 and -ftree-parallelize-loops [checkme: tree-optimization SVN r154748])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154878])
re PR debug/42234 (internal compiler error: verify_ssa failed [checkme: c++ SVN r154879])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154885])
re PR middle-end/41611 (guard variable is emitted even when the guarded symbol isn't [checkme: c++ SVN r154965])
re PR libstdc++/42381 (deque shouldn't reserve that much memory [checkme: libsdtc++ SVN r155271])
re PR tree-optimization/42386 (ICE in ipcp_iterate_stage, at ipa-cp.c:766 [checkme: c++ SVN r155321])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r155765])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156010])
re PR ada/42068 (ICE in function_and_variable_visibility [checkme: middle-end SVN r156016])
re PR debug/42991 (cfgexpand.c:2487: Conditional jump or move depends on uninitialised value(s) [checkme: middle-end SVN r156575])
re PR c/43125 (Revision 156907 failed gcc.dg/attr-used.c [checkme: middle-end SVN r156927])
re PR rtl-optimization/43058 (var-tracking uses up all virtual memory [checkme: debug SVN r157547])
re PR c/43661 (ice in fold_comparison, at fold-const.c:9579 [checkme: middle-end SVN r157984])
re PR debug/42425 (ICE declaring local class [checkme: lto SVN r158722])
re PR c++/43080 (ICE with anonymous union and -flto [checkme: lto SVN r158723])
re PR c++/40561 (code does not compile -- compiles fine when replacing != with !(==) [checkme: middle-end SVN r158778])
re PR c/44024 (missed optimization [checkme: middle-end SVN r159205])
re PR middle-end/44104 (New test failures [checkme: debug SVN r159367])
re PR c++/44256 (When using -flto and -fwhole-program the compiler/linker crash [checkme: lto SVN r159779])
re PR lto/44248 (-fcompare-debug failure with -flto/-fwhopr -g [checkme: debug SVN r161056])
backport: re PR middle-end/44104 (New test failures [checkme: debug SVN r161666])
re PR fortran/44882 (Bogus types in references with mismatched commons [checkme: tree-optimization SVN r161990])
re PR debug/44689 (-fenable-icf-debug causes segfault in cp_function_decl_explicit_p [checkme: fortran SVN r162052])
re PR c++/36960 (Reference variable in virtually inherited base corrupted under optimization [checkme: tree-optimization SVN r162141])
re PR c++/45382 (internal compiler error: tree code ‘call_expr’ is not supported in gimple streams [checkme: lto SVN r165471])
re PR tree-optimization/20165 (Pointer does not really escape with write [checkme: fortran SVN r165559])
re PR rtl-optimization/45834 (Redundant inter-loop edges in DDG [checkme: c SVN r165781])
re PR c++/46134 (constexpr vs. defaulted ctor [checkme: INVALID SVN r166171])
re PR debug/46241 (ice in dwarf2out.c [checkme: middle-end SVN r166245])
re PR rtl-optimization/33172 (Optimizer fails to elid away unreferenced static function [checkme: tree-optimize SVN r166557])
re PR fortran/38669 (Array bounds violation for arguments of elemental subroutine [checkme: tree-optimize SVN r166579])
re PR rtl-optimization/42889 ("-fcompare-debug failure (length)" with "-O1 -fgcse" [checkme: debug SVN r166719])
re PR middle-end/46297 (gfortran.dg/g77/980701-0.f FAILs with -Os -fno-asynchronous-unwind-tables [checkme: middle-end-optimization SVN r166905])
re PR driver/44986 (-fuse-linker-plugin -save-temps gives resolution file base name of last argument [checkme: lto SVN r167292])
re PR c++/44871 (Invalid type mismatches while merging C and C++ sources [checkme: lto SVN r167367])
re PR middle-end/46745 ('#'mem_ref' not supported by dump_expr#<expression error>' [checkme: c SVN r167433])
re PR driver/46760 (LTO bootstrap doesn't work with FDO [checkme: tree-optimization SVN r167458])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r167487])
re PR lto/46576 (BFD linker plugin generates bad executables [checkme: debug SVN r167738])
re PR middle-end/46885 (ICE: in gsi_insert_seq_nodes_after, at gimple-iterator.c:251 with -ftree-parallelize-loops -g [checkme: debug SVN r167801])
re PR tree-optimization/46469 (ICE: verify_cgraph_node failed: inline clone is needed at -O [checkme: tree-optmization SVN r168598])
re PR c/32511 (GCC rejects inline+weak function [checkme: middle-end SVN r168652])
re PR tree-optimization/46583 (-fcompare-debug failure with -O -fno-inline -fipa-cp -fipa-cp-clone [checkme: debug SVN r169058])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169310])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169377])
re PR libgomp/47464 (Many gomp failures [checkme: rtl-optimization SVN r169634])
re PR preprocessor/47311 ([C++0x] ICE in tsubst @cp/pt.c:10502 [checkme: c++ SVN r169677])
re PR rtl-optimization/42631 ("-fcompare-debug failure" with "-O1 -funroll-loops" [checkme: debug SVN r169851])
re PR debug/47647 (BLOCKs are empty [checkme: lto SVN r170321])
re PR debug/47283 (ICE in refs_may_alias_p_1, at tree-ssa-alias.c [checkme: middle-end SVN r170650])
re PR c++/48073 (ICE with -flto in templated C++ code [checkme: lto SVN r170875])
re PR c++/13954 ([tree-ssa] SRA does not work for classes that use inheritance with an empty base [checkme: tree-optimization SVN r170994])
re PR driver/46944 (gcc should accept -fuse-linker-plugin only if linker handles -plugin [checkme: lto SVN r171039])
re PR c/48146 (ICE tree check: expected ssa_name, have var_decl in has_zero_uses, at tree-flow-inline.h:342 [checkme: tree-optimization SVN r171045])
re PR c/48650 (valgrind: Invalid write of size 8 in build_string (tree.c:1524) [checkme: middle-end SVN r172642])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172649])
re PR c++/46364 (basic_string.h:541:32: internal compiler error: Segmentation fault [checkme: middle-end SVN r172650])
re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172706])
re PR debug/48207 (ICE in lhd_set_decl_assembler_name, at langhooks.c:158 [checkme: lto SVN r172708])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172765])
backport: re PR middle-end/47976 (Recent gfortran.dg/actual_array_constructor_3.f90 regression on arm-linux-gnueabi [checkme: fortran SVN r172766])
re PR c/47892 (Fails to vectorize comparison code, if-conversion fails [checkme: tree-optimization SVN r172774])
re PR debug/48703 (segfault in canonicalize_for_substitution [checkme: lto SVN r172830])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172963])
re PR c/48731 (regression: __attribute__((flatten)) produces error with function calling variadic functions [checkme: tree-optimization SVN r172964])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173876])
re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r173877])
re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r173901])
backport: re PR c/48985 (bogus buffer overflow warning and abort on static flexible array member [checkme: middle-end SVN r174476])
re PR java/23754 (tree check error in check_inner_circular_reference [checkme: lto SVN r175174])
re PR middle-end/49373 (Many testcase failures [checkme: tree-optimize SVN r175336])
re PR rtl-optimization/49686 (CFI notes are missed for delayed slot [checkme: debug SVN r176091])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176448])
backport: re PR c++/49039 (LLVM StringRef miscompilation with -O2 [checkme: tree-optimization SVN r176481])
re PR tree-optimization/49957 (Fails to SLP in 410.bwaves [checkme: fortran SVN r177368])
re PR middle-end/37221 (Missed early loop-unroll optimization - causes 40% degradation on SPU [checkme: fortran SVN r177486])
re PR debug/50006 (ICE in in connect_traces, at dwarf2cfi.c:2677 [checkme: middle-end SVN r177764])
re PR rtl-optimization/50191 (Strange debug insn produced for TOC compiling 416.gamess with profile-generate [checkme: debug SVN r178625])
re PR libgomp/50386 (libgomp.h:87:5: error: unnamed struct/union that defines no instances [checkme: middle-end SVN r179285])
re PR middle-end/49310 (Compile time hog in var-tracking emit [checkme: debug SVN r180194])
re PR driver/41844 (lto1: warning: unknown register name: line-length-none [checkme: lto SVN r180517])
re PR debug/51262 (ICE: SIGSEGV in primary_template_instantiation_p (pt.c:2874) with -flto -g [checkme: lto SVN r182221])
re PR debug/48354 (internal compiler error: in splice_child_die, at dwarf2out.c:8064 [checkme: lto SVN r182286])
re PR debug/51564 (ICE in force_type_die, at dwarf2out.c:19288 [checkme: lto SVN r182367])
re PR debug/51567 (ICE in splice_child_die, at dwarf2out.c:5009 with -flto -g [checkme: lto SVN r182377])
re PR tree-optimization/51557 (ICE: in maybe_record_trace_start, at dwarf2cfi.c:2244 with custom flags [checkme: debug SVN r182404])
re PR debug/46796 (debug info missing builtin type names with lto [checkme: lto SVN r182524])
re PR debug/51650 (LTO ICE in dwarf2out_finish, at dwarf2out.c:22501 while building libxul [checkme: lto SVN r182625])
re PR c/51730 (autoconf 2.60 through 2.67 stdbool.h check fails with GCC 4.7 [checkme: middle-end SVN r182830])
re PR c/8081 (ICE with variably sized types returned from nested functions [checkme: middle-end SVN r183153])
re PR c++/53207 (bool conversion on return [checkme: tree-optimization SVN r184623])
re PR c++/52582 (g++ ICE when compiling qt-4.8.0 with -O2 on PPC (32bit) [checkme: middle-end SVN r185381])
re PR c++/52772 (internal compiler error: Segmentation fault [checkme: middle-end SVN r186011])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186494])
re PR c/52977 (internal compiler error: Segmentation fault with `-x c-header' or `-x cxx-header' option [checkme: middle-end SVN r186593])
re PR c++/53050 (ssa_forward_propagate_and_combine: segmentation fault [checkme: tree-optimization SVN r186620])
re PR c/11586 (after call sigaction, system() return wrong status [checkme: INVALID SVN r187542])
re PR rtl-optimization/53373 (ICE on valid code with -mavx [checkme: rtl-optimzation SVN r187695])
re PR fortran/53148 (Incorrect intrinsic function parsing on labeled statements when compiled w/ -ffrontend-optimize [checkme: c SVN r187718])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187931])
re PR c++/53505 (bitfield with bool type generated broken object file [checkme: tree-optimization SVN r187932])
re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188298])
re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188386])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188387])
backport: re PR middle-end/53616 (416.gamess in SPEC CPU 2006 miscompiled [checkme: c++ SVN r188615])
backport: re PR c/53580 (Internal Segmentation fault in nested "omp parallel", "omp parallel for" and "omp parallel for reduction" Directives [checkme: middle-end SVN r188625])
re PR debug/53470 (ICE when linking with -g in splice_child_die, at dwarf2out.c:4264 [checkme: middle-end SVN r188811])
re PR rtl-optimization/53706 (Bootstrap failure due to "Invalid write of size 8 at 0xBDC35E: variable_htab_free (var-tracking.c:1418) [checkme: debug SVN r189037])
re PR c/53937 (Pack'ing struct causes gcc to not recognize that an field's address is aligned [checkme: middle-end SVN r189458])
re PR web/53919 (Version-specific install instructions not available [checkme: c++ SVN r189545])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190533])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r190534])
re PR tree-optimization/54295 (Widening multiply-accumulate operation uses wrong value extension [checkme: tree-ssa SVN r191066])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191614])
re PR middle-end/54649 (Go bootstrap failed [checkme: go SVN r191615])
re PR middle-end/53024 (Support vector_size that is not a power of 2 [checkme: c SVN r191800])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192119])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192121])
re PR c/33763 (Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining [checkme: tree-optimization SVN r192122])
re PR lto/54980 (gimple check: expected gimple_cond(error_mark), have gimple_call() in gimple_cond_set_lhs, at gimple.h:2578 [checkme: tree-optimize SVN r192809])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193331])
re PR fortran/48636 (Enable more inlining with -O2 and higher [checkme: middle-end SVN r193406])
re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r193649])
re PR rtl-optimization/55717 (ICE in form_sum, at reload.c:5400 [checkme: debug SVN r194575])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r194680])
re PR tree-optimization/55875 (IVopts caused miscompilation [checkme: tree-optimiation SVN r195054])
re PR inline-asm/55775 (ICE when building pari [checkme: middle-end SVN r195173])
re PR libstdc++/51083 (TR1 [tr.c99.cmath.over] and C++11 [cmplx.over] overloads not constrained [checkme: tree-optimizatoin SVN r195274])
re PR rtl-optimization/55273 (ICE in iv_number_of_iterations, at loop-iv.c:2819 [checkme: tree-optimizatoin SVN r195275])
re PR libffi/56000 (FAIL: libffi.call/cls_uchar_va.c -O0 -W -Wall output pattern test [checkme: middle-end SVN r195277])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195541])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195542])
re PR debug/54410 (doubled DW_TAG_template_type_param [checkme: c++ SVN r195613])
re PR sanitizer/55561 (TSAN: provide a TSAN instrumented libgomp [checkme: libgomp SVN r195618])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r195632])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195646])
backport: re PR debug/55094 (ICE in maybe_record_trace_start, at dwarf2cfi.c:2224 [checkme: middle-end SVN r195650])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: tree-optimization SVN r195707])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195751])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195758])
re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r195796])
re PR fortran/55789 (Needless realloc with array constructor. [checkme: tree-optimization SVN r195844])
re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196133])
backport: re PR c++/56217 (ICE: OpenMP: when combining shared() and a move constructor [checkme: middle-end SVN r196141])
backport: re PR c++/56381 (ICE: cc1plus: internal compiler error: in gimplify_expr, at gimplify.c:7842 [checkme: tree-optimization SVN r196149])
re PR c/56113 (out of memory when compiling a function with many goto labels (50k > ) [checkme: middle-end SVN r196769])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197047])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197048])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197201])
re PR c++/56694 (Internal compiler error when compiling OpenMP code [checkme: middle-end SVN r197203])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197349])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197350])
re PR c++/56768 ([4.7] ICE in make_decl_rtl, at varasm.c:1147 [checkme: middle-end SVN r197351])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197420])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197421])
re PR c++/56819 (ICE: SIGSEGV in int_cst_value (tree.h:4013) with -fcompare-debug [checkme: debug SVN r197454])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198445])
re PR sanitizer/57104 (ICE: in expand_expr_addr_expr_1, at expr.c:7594 with -fsanitize=thread and hardreg variable [checkme: tree-optimization SVN r198446])
re PR c++/57038 (Latest libreoffice compilation fails with enabled LTO [checkme: lto SVN r198917])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199282])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199283])
re PR tree-optimization/57385 ([tree-ssa] Possible segfault in fully_constant_vn_reference_p [checkme: tree-ssa SVN r199284])
re PR c++/57208 (Latest chromium compilation fails with enabled LTO [checkme: lto SVN r200468])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201696])
re PR middle-end/56417 (internal compiler error: verify_gimple failed [checkme: sanitizer SVN r201697])
re PR c++/58201 (Undefined reference to `B::B(void const**)' [checkme: middle-end SVN r202298])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202496])
re PR c++/58377 (spurious "may be used uninitialized" warning with -Og [checkme: middle-end SVN r202498])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202564])
re PR libgomp/58392 (internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c (omp simd inside omp parallel) [checkme: tree-optimization SVN r202565])
re PR c/20318 (RFE: add attribute to specify that a function never returns NULL [checkme: tree-optimization SVN r203316])
re PR c/52862 (ICE convert_to_pointer, at convert.c:50 [checkme: plugin SVN r204650])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205481])
re PR debug/59323 (Int. comp. error: in add_AT_specification, at dwarf2out.c:4026 [checkme: lto SVN r205487])
backport: re PR target/59405 (Incorrect FP<->MMX transition during call/ret [checkme: INVALID SVN r205790])
re PR middle-end/59399 (ICE in expand_expr_real_1 with -m64 -fsanitize=signed-integer-overflow [checkme: sanitizer SVN r205888])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205991])
re PR c++/58477 (ice in cgraph_speculative_call_info [checkme: middle-end SVN r205993])
re PR fortran/45586 (ICE non-trivial conversion at assignment [checkme: lto SVN r206461])
re PR c++/58252 (ice in gimple_get_virt_method_for_binfo with -O2 [checkme: ipa SVN r206516])
re PR fortran/59706 (ICE with do concurrent and internal subprogram [checkme: middle-end SVN r206732])
re PR ipa/59469 (LLVM build failure with gcc LTO [checkme: c++ SVN r207366])
re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r207695])
re PR fortran/60060 (lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096 [checkme: lto SVN r207715])
backport: re PR middle-end/59776 (gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865 [checkme: debug SVN r208366])
re PR c++/60474 (Crash in tree_class_check [checkme: middle-end SVN r208451])
re PR c++/60553 (segfault in gt_ggc_mx_lang_tree_node in Chromium with LTO [checkme: middle-end SVN r208682])
re PR c++/60750 (double free after std::move on string inside throw when compiled with optimization [checkme: middle-end SVN r209179])
re PR libfortran/60706 (FAIL: gfortran.dg/size_kind_2.f90  -O   scan-tree-dump original "var2 = 42949673 00;" [checkme: middle-end SVN r209216])
re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209468])
backport: re PR c++/60836 (invalid PHI argument and ICE in verify_gimple [checkme: tree-optimization SVN r209630])
re PR debug/61070 (debug_bitmap writes to stdout [checkme: middle-end SVN r210098])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210181])
re PR sanitizer/61095 (miscompile: tsan is broken in gcc trunk, works in 4.9 [checkme: tree-optimization SVN r210203])
re PR c/61136 (ice in tree_nop_conversion [checkme: tree-optimization SVN r210312])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210426])
re PR gcov-profile/60897 (Mangled function name in warning during -fprofile-use phase of Firefox build [checkme: ipa SVN r210472])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212174])
re PR middle-end/60226 (ICE initializing array of elements with too large alignment [checkme: c SVN r212346])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r212436])
re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212521])
backport: re PR c/61779 (gcc -Og fails with impossible constraint on legal C code [checkme: tree-optimization SVN r212741])
re PR ipa/61921 (ICE: SIGSEGV in varpool_node::get_constructor(), at varpool.c:275 with -O2 -fipa-pta [checkme: tree-optimization SVN r213114])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r213308])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213491])
re PR c++/61455 (Internal compiler error, and other confused errors, when using array notation [checkme: middle-end SVN r213492])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213812])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213901])
re PR c/62073 (Segmentation fault with tree vectorize [checkme: tree-optimization SVN r213904])
re PR preprocessor/60975 (-Wvariadic-macros does not print warning [checkme: c SVN r214200])
re PR c++/62175 (Internal compiler error in gimplify_modify_expr gimplify.c:4616 [checkme: tree-optimization SVN r214492])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214543])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r214546])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r214678])
re PR ipa/61659 (Extra undefined symbol because of devirtualization [checkme: c++ SVN r215134])
re PR c++/63419 (verify_gimple failed: "vector CONSTRUCTOR element is not a GIMPLE value" [checkme: tree-optimization SVN r216138])
re PR c++/62127 (ICE with VLA in constructor [checkme: tree-optimization SVN r216150])
re PR middle-end/58624 (gcc internal compiler error: Segmentaion fault in insert_to_assembler_name_hash [checkme: c++ SVN r216273])
re PR c/63554 (ice in "execute_todo, at passes.c:1797" with -O3 [checkme: middle-end SVN r216315])
re PR middle-end/63879 (ICE compiling Linux Kernel fs/ext3/namei.c with -fsanitize=undefined [checkme: sanitizer SVN r217766])
re PR tree-optimization/64004 ([5 Regressio] Build error in tree-ssa-loop-niter.c in maybe_lower_iteration_bound [checkme: java SVN r218018])
re PR tree-optimization/64121 (ICE: SSA corruption with -O -fsanitize=undefined [checkme: sanitizer SVN r218222])
re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220152])
re PR sanitizer/64717 (-fsanitize=vptr leads to warning: ‘<anonymous>’ may be used uninitialized in this function [-Wmaybe-uninitialized] [checkme: c++ SVN r220262])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220327])
backport: re PR middle-end/64766 (internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:122 [checkme: c SVN r220335])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220420])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220617])
backport: re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220622])
re PR middle-end/64824 (ICE in gimple verification [checkme: c SVN r220624])
re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r221776])
re PR c++/65626 (ICE in fixup_noreturn_call called by tree-ssa-forwprop.c:2492 [checkme: middle-end SVN r221790])
re PR middle-end/65554 (ICE: verify_gimple failed [checkme: c++ SVN r221808])
re PR c++/65851 (ice in set_lattice_value at tree-ssa-cc p.c:535 [checkme: tree-optimization SVN r222510])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222514])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222843])
re PR fortran/62283 (basic-block vectorization fails [checkme: tree-optimization SVN r222849])
re PR ipa/65701 (r221530 makes 187.facerec drop with -Ofast -flto on bdver2 [checkme: tree-optimization SVN r223528])
backport: re PR middle-end/65597 (ICE in build_outer_var_ref, at omp-low.c:1043 [checkme: fortran SVN r224090])
re PR debug/66503 (missing DW_AT_abstract_origin for cross-unit call sites [checkme: middle-end SVN r224372])
re PR rtl-optimization/66351 (r223883 miscompiles stage2 compiler on ia64 [checkme: ipa SVN r224719])
re PR preprocessor/53690 ([C++11] \u0000 and \U00000000 are wrongly encoded as U+0001. [checkme: c++ SVN r225353])
re PR ipa/66793 (ICE at -Os and above on x86_64-linux-gnu (verify_flow_info failed) [checkme: tree-optimization SVN r225546])
re PR lto/66468 (ICE in in check_die, at dwarf2out.c:5719 [checkme: debug SVN r226255])
re PR c/67107 (ICE: SIGSEGV in tree_class_check with -frounding-math -funsafe-math-optimizations [checkme: middle-end SVN r226609])
re PR c/67279 (-fsanitize=undefined spurious error: initializer element is not constant [checkme: sanitizer SVN r227491])
re PR c/48885 (missed optimization with restrict qualifier? [checkme: tree-optimization SVN r228073])
re PR fortran/67170 (PRE can't hoist out a readonly argument [checkme: tree-optimization SVN r228244])
re PR c/67882 (surprising offsetof result on an invalid array member without diagnostic [checkme: c++-common SVN r229717])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230897])
re PR sanitizer/67941 (calls on function pointer from a captureless lambda cause ubsan warning [checkme: c++ SVN r230901])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231100])
re PR ada/68590 (FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check" [checkme: middle-end SVN r231110])
re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231217])
re PR middle-end/68656 (warning about disabled var-tracking uses odd location info [checkme: c SVN r231292])
backport: re PR c++/68184 (Exception from a virtual function does not get caught [checkme: ipa SVN r231677])
re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r232122])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232169])
re PR middle-end/68983 (ICE: in store_field, at expr.c:6659 [checkme: c++ SVN r232171])
re PR tree-optimization/69164 (ICE in create_tmp_var, at gimple-expr.c:468 [checkme: c++ SVN r232187])
re PR debug/69077 (omnetpp ICEs with -flto -g [checkme: lto SVN r232272])
re PR c++/66487 (sanitizer/warnings for lifetime DSE [checkme: ipa SVN r232356])
re PR tree-optimization/69355 (Wrong results with -O1 optimization [checkme: c++ SVN r232663])
re PR c++/69267 ([cilkplus] ICE when calling a function with an empty class as an argument [checkme: cilkplus SVN r232887])
re PR middle-end/69643 (Address space discarded [checkme: c SVN r233189])
re PR middle-end/69537 (Incorrect -Wmaybe-uninitialized warning with enum variable [checkme: go SVN r233235])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233288])
backport: re PR c/68960 (__attribute__ ((aligned ())) is ignored for OpenMP private variables [checkme: middle-end SVN r233327])
re PR tree-optimization/69110 (execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2 [checkme: fortran SVN r233782])
re PR middle-end/70054 (GCC 6 gives a strict-aliasing warning on use of std::aligned_storage [checkme: c++ SVN r233961])
re PR sanitizer/70135 (-fsanitize=undefined causes static_assert to fail [checkme: c++ SVN r234064])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234248])
re PR sanitizer/70147 (testcase from hana testsuite gets miscompiled with -fsanitize=undefined [checkme: c++ SVN r234249])
re PR tree-optimization/70144 (g++ ICE at -O1 and above on valid code on x86_64-linux-gnu in "copy_reference_ops_from_ref" [checkme: c++ SVN r234297])
re PR middle-end/70280 (-fcompare-debug failure (length) with --param=integer-share-limit=4016 -mavx512bw [checkme: c SVN r234312])
re PR middle-end/70273 (FAIL: g++.dg/ext/label13a.C  -std=gnu++98 execution test / scan-assembler _ZN1CC4Ev [checkme: c++ SVN r234386])
re PR preprocessor/69650 (ICE in linemap_line_start, at libcpp/line-map.c:803 [checkme: lto SVN r234481])
re PR middle-end/70307 (ICE: in gimplify_expr, at gimplify.c:10915 on valid code [checkme: c SVN r234706])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235063])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235065])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235081])
re PR c++/70018 (Possible issue around IPO and C++ comdats discovered as pure/const [checkme: ipa SVN r235318])
re PR go/49889 (Calling a function whose name is obscured by a local variable does not produce an error [checkme: middle-end SVN r235484])
re PR fortran/70931 (ICE with -g in native_encode_initializer, bei dwarf2out.c:17768 [checkme: middle-end SVN r235944])
re PR ada/70786 (Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available) [checkme: tree-optimization SVN r236086])
re PR middle-end/71249 (-Wswitch-unreachable false positive for a compound statement containing a used label [checkme: c SVN r236649])
re PR middle-end/50060 (intrinsics not folded by the middle-end [checkme: c++ SVN r238520])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238579])
re PR libgomp/71941 (ICE with OpenMP tasks and queue [checkme: c++ SVN r238580])
re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239855])
re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239904])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r239930])
backport: re PR tree-optimization/77352 (ICE: verify_ssa failed [checkme: fortran SVN r239933])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240006])
re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r240025])
re PR rtl-optimization/64316 (ICE in simplify_const_unary_operation after r218503 [checkme: ipa SVN r240081])
re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r240348])
re PR fortran/77678 (ICE in fold_read_from_constant_string, at fold-const.c:13706 [checkme: middle-end SVN r240351])
re PR rtl-optimization/77714 (Wrong code generation for gcc.c-torture/execute/pr51447.c [checkme: rlt-optimization SVN r240518])
re PR c++/78051 (error: dead STMT in EH table when using -O2 [checkme: tree-optimization SVN r241394])
re PR tree-optimization/35503 (Warning about restricted pointers? [checkme: c SVN r242366])
re PR tree-optimization/66419 (FAIL: gcc.target/aarch64/aapcs64/va_arg-6.c execution,  -O3 -g [checkme: debug SVN r243126])
re PR tree-optimization/78692 (ICE (segfault) [checkme: c++ SVN r243377])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r243387])
re PR middle-end/78622 (-Wformat-length/-fprintf-return-value incorrect with overflow/wrapping [checkme: fortran SVN r243765])
re PR middle-end/79089 (error: incorrect sharing of tree nodes [checkme: c SVN r244507])
backport: re PR tree-optimization/77450 (ICE: in verify_ssa, at tree-ssa.c:1016 on very simple code with vectors [checkme: c SVN r244870])
re PR c++/79129 (ICE with -fdebug-types-section starting with r240578 [checkme: debug SVN r244955])
re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245053])
re PR tree-optimization/79347 (vect_do_peeling is messing up profile [checkme: tree-ssa SVN r245196])
re PR middle-end/56727 (Recursive call goes through the PLT unnecessarily [checkme: tree-ssa SVN r245359])
backport: re PR c++/79267 (internal compiler error with -O3 or -O2 -finline-functions [checkme: tree-optimization SVN r245466])
re PR inline-asm/79552 (Wrong code generation due to -fschedule-insns, with __restrict__ and inline asm [checkme: tree-optimization SVN r245528])
re PR rtl-optimization/79286 (ira and lra wrong code at -O2 and -Os on i686-linux [checkme: rtl-optimizatoin SVN r245714])
re PR c/79731 (ICE: verify_gimple failed [checkme: middle-end SVN r245779])
re PR middle-end/79756 (ICE in execute_todo, at passes.c:2011 [checkme: c SVN r245838])
re PR fortran/79894 (ICE in gfc_add_modify_loc, at fortran/trans.c:159 [checkme: tree-optimization SVN r245923])
re PR c++/80075 (ICE: "statement marked for throw, but doesn’t" with -fnon-call-exceptions [checkme: middle-end SVN r246223])
re PR middle-end/67338 (fold-const sanitizer runtime error  in roundup_loc [checkme: c SVN r246305])
re PR ipa/78644 (ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp [checkme: tree-optimization SVN r246534])
re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r246621])
re PR middle-end/80163 (ICE on hopefully valid code [checkme: c SVN r246876])
re PR c++/69953 (Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail [checkme: lto SVN r246899])
re PR fortran/80494 (ICE in wide_int_to_tree [checkme: tree-optimization SVN r247095])
backport: re PR sanitizer/79572 (reference binding to null pointer not reported with -fsanitize=undefined [checkme: c++ SVN r247694])
backport: re PR c++/77363 (Missing debug information in DWARF [checkme: debug SVN r248602])
backport: re PR tree-optimization/77665 (ICE in expand_GOMP_SIMD_VF, at internal-fn.c:172 [checkme: fortran SVN r248612])
re PR sanitizer/81065 (UBSAN: false positive as a result of distribution involving different types [checkme: middle-end SVN r249144])
re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249174])
re PR sanitizer/81097 (UBSAN: false positive for not existing negation operator and a bogus message [checkme: middle-end SVN r249407])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249479])
backport: re PR sanitizer/80973 (ICE with lambda and -fsanitize=undefined [checkme: c++ SVN r249510])
re PR sanitizer/81505 (ICE in tree-ssa-loop-manip.c:95 with -fsanitize=signed-integer-overflow [checkme: middle-end SVN r250494])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r250853])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r251143])
re PR c++/82054 (ICE in add_dwarf_attr with -fopenmp and -g [checkme: middle-end SVN r251559])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251661])
re PR c++/82084 (ICE: constructing wstring with -O3 [checkme: tree-optimization SVN r251711])
re PR sanitizer/81148 (UBSAN: two more false positives [checkme: middle-end SVN r252277])
re PR fortran/81827 (Large compile time with derived-type rrays [checkme: tree-optimization SVN r252458])
re PR debug/82144 (ICE in add_dwarf_attr with alignas [checkme: middle-end SVN r253134])
re PR c/82765 (ICE at -Os on valid code on x86_64-linux-gnu: in tree_to_shwi, at tree.c:6611 [checkme: middle-end SVN r254337])
re PR fortran/83017 (DO CONCURRENT not parallelizing [checkme: tree-optimization SVN r254867])
re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255354])
re PR middle-end/83415 (ICE during gimplification of assignment to read-only vector [checkme: c SVN r255629])
re PR sanitizer/83388 (reference statement index not found error with -fsanitize=null [checkme: lto SVN r255694])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r255722])
re PR ipa/81877 (Incorrect results with lto and -fipa-cp and -fipa-cp-clone [checkme: tree-optimization SVN r255776])
re PR c++/83482 (internal compiler error: Segmentation fault [checkme: tree-optimization SVN r255817])
re PR debug/83694 (New test case gcc.dg/pr83666.c from r256232 ICEs [checkme: middle-end SVN r256307])
re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256341])
re PR rtl-optimization/81308 (ICE in calc_dfs_tree, at dominance.c:458 [checkme: rtl-optimizatin SVN r256349])
re PR c++/80763 (-O3 causes error: inline clone in same comdat group list [checkme: ipa SVN r256369])
backport: re PR c++/83713 (ICE in do_narrow at gcc/convert.c:474 [checkme: middle-end SVN r256371])
re PR c++/86620 (__attribute__((no inline)) gives incorrect warning with overloaded functions [checkme: rtl-optimization SVN r256729])
re PR fortran/84000 (ICE in replace_loop_annotate, at tree-cfg.c:352 [checkme: middle-end SVN r257011])
re PR libgomp/84086 ([8 Regresssion] segfault in instantiate_scev_r for libgomp.fortran/examples-4/simd-2.f90 -O1 [checkme: tree-optimization SVN r257152])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257721])
re PR c/84190 (double arithmetic on x86 no longer rounds to nearest [checkme: tree-optimization SVN r257722])
re PR libgomp/84466 (libgomp.graphite/force-parallel-8.c fails starting with r257723 [checkme: tree-optimization SVN r258035])
re PR c/84607 (Side effects discarded in address computation inside 'if' [checkme: middle-end SVN r258061])
re PR debug/85176 (ICE in force_decl_die, at dwarf2out.c:25910 [checkme: lto SVN r259080])
re PR rtl-optimization/85302 (ICE in size_of_loc_descr, at dwarf2out.c:1771 on i686-linux-gnu [checkme: debug SVN r259311])
re PR c/86046 (ICE in execute_todo, at passes.c:2043 [checkme: tree-optimization SVN r261193])
backport: re PR sanitizer/81212 (-Wreturn-type is disabled when used together with -fsanitize=return [checkme: c++ SVN r262042])
re PR debug/86523 (ICE in gen_member_die, at dwarf2out.c:24933 starting from r262560 [checkme: lto SVN r262696])
re PR debug/86456 (Segfault in switch_to_section at  gcc/varasm.c:7353 since r259317 [checkme: lto SVN r262819])
re PR lto/86654 (ICE in gen_member_die, at dwarf2out.c:24933 [checkme: debug SVN r262965])
re PR c++/78655 (gcc doesn't exploit the fact that the result of pointer addition can not be nullptr [checkme: tree-optimization SVN r263662])
re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r263967])
backport: re PR sanitizer/87095 (UndefinedBehaviorSanitizer vptr false positive with virtual inheritance only with -fno-sanitize-recover [checkme: c++ SVN r264107])
re PR middle-end/41453 (use INTENT(out) for optimization [checkme: fortran SVN r264506])
re PR c/87682 (gcc/mem-stats.h:172: possible broken comparison operator ? [checkme: middle-end SVN r265376])
re PR c++/87469 (ice in record_estimate, at tree-ssa-loop-niter.c:3271 [checkme: middle-end SVN r265605])
re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r265776])
re PR c/87953 (asan: stack-buffer-overflow in vectorizable_reduction [checkme: tree-optimization SVN r265964])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266014])
backport: re PR c++/58372 (internal compiler error: ix86_compute_frame_layout [checkme: middle-end SVN r266015])
re PR target/86677 (popcount builtin detection is breaking some kernel build [checkme: INVALID SVN r266039])
re PR c++/87229 (ICE: tree code 'call_expr' is not supported in LTO streams [checkme: lto SVN r266372])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266550])
re PR fortran/88229 (ICE tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5608 [checkme: tree-optimization SVN r266553])
re PR tree-optimization/88367 (-fno-delete-null-pointer-checks doesn't work properly [checkme: c SVN r266878])
re PR c/87944 (Wrong code with LRA pushing stack local variable [checkme: fortran SVN r267184])
re PR tree-optimization/88606 (ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR) [checkme: c SVN r268540])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268748])
re PR tree-optimization/71237 (scev tests failing after pass reorganization [checkme: fortran SVN r268750])
re PR lto/89514 (-g -fdebug-types-section -flto gives 'Dwarf Error: bad length' in gdb [checkme: debug SVN r269250])

Re: Commit messages and the move to git

[Joseph Myers]

On Fri, 20 Dec 2019, Jonathan Wakely wrote:

> I've sent another pull request fixing another 20. Here is the list
> with those 20 removed (and this still includes the libcpp vs
> preprocessor ones that will be handled by the new alias).

Thanks, merged.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Commit messages and the move to git

[Jonathan Wakely]

On Fri, 20 Dec 2019 at 22:58, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Fri, 20 Dec 2019, Jonathan Wakely wrote:
>
> > I've sent another pull request fixing another 20. Here is the list
> > with those 20 removed (and this still includes the libcpp vs
> > preprocessor ones that will be handled by the new alias).
>
> Thanks, merged.

... aaaaaand another merge request :-)

Going to sleep now though, so that's all from me for now.

Re: Commit messages and the move to git

[Joseph Myers]

On Fri, 20 Dec 2019, Jonathan Wakely wrote:

> On Fri, 20 Dec 2019 at 22:58, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Fri, 20 Dec 2019, Jonathan Wakely wrote:
> >
> > > I've sent another pull request fixing another 20. Here is the list
> > > with those 20 removed (and this still includes the libcpp vs
> > > preprocessor ones that will be handled by the new alias).
> >
> > Thanks, merged.
> 
> ... aaaaaand another merge request :-)

Thanks, merged.  (This last one won't be in the conversion I'm running 
right now.)

-- 
Joseph S. Myers
joseph@codesourcery.com