* Commit messages and the move to git @ 2019-11-04 10:29 Richard Earnshaw (lists) 2019-11-04 12:11 ` Arnaud Charlet ` (4 more replies) 0 siblings, 5 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-04 10:29 UTC (permalink / raw) To: GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 10:29 Commit messages and the move to git Richard Earnshaw (lists) @ 2019-11-04 12:11 ` Arnaud Charlet 2019-11-04 12:43 ` Martin Jambor ` (3 subsequent siblings) 4 siblings, 0 replies; 139+ messages in thread From: Arnaud Charlet @ 2019-11-04 12:11 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: GCC Development, 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 10:29 Commit messages and the move to git Richard Earnshaw (lists) 2019-11-04 12:11 ` Arnaud Charlet @ 2019-11-04 12:43 ` Martin Jambor 2019-11-04 17:43 ` Segher Boessenkool 2019-11-04 16:04 ` Jeff Law ` (2 subsequent siblings) 4 siblings, 1 reply; 139+ messages in thread From: Martin Jambor @ 2019-11-04 12:43 UTC (permalink / raw) To: GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 12:43 ` Martin Jambor @ 2019-11-04 17:43 ` Segher Boessenkool 0 siblings, 0 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-04 17:43 UTC (permalink / raw) To: Martin Jambor; +Cc: GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 10:29 Commit messages and the move to git Richard Earnshaw (lists) 2019-11-04 12:11 ` Arnaud Charlet 2019-11-04 12:43 ` Martin Jambor @ 2019-11-04 16:04 ` Jeff Law 2019-11-04 16:18 ` Richard Earnshaw (lists) ` (2 more replies) 2019-11-04 16:19 ` Jonathan Wakely 2019-11-05 2:51 ` Kewen.Lin 4 siblings, 3 replies; 139+ messages in thread From: Jeff Law @ 2019-11-04 16:04 UTC (permalink / raw) To: Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 16:04 ` Jeff Law @ 2019-11-04 16:18 ` Richard Earnshaw (lists) 2019-11-05 15:48 ` Richard Earnshaw 2019-11-07 14:27 ` Eric S. Raymond 2 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-04 16:18 UTC (permalink / raw) To: Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 16:04 ` Jeff Law 2019-11-04 16:18 ` Richard Earnshaw (lists) @ 2019-11-05 15:48 ` Richard Earnshaw 2019-11-07 14:27 ` Eric S. Raymond 2 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw @ 2019-11-05 15:48 UTC (permalink / raw) To: Jeff Law, GCC Development [-- 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 16:04 ` Jeff Law 2019-11-04 16:18 ` Richard Earnshaw (lists) 2019-11-05 15:48 ` Richard Earnshaw @ 2019-11-07 14:27 ` Eric S. Raymond 2019-11-08 13:43 ` Richard Earnshaw (lists) 2 siblings, 1 reply; 139+ messages in thread From: Eric S. Raymond @ 2019-11-07 14:27 UTC (permalink / raw) To: Jeff Law; +Cc: Richard Earnshaw (lists), GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-07 14:27 ` Eric S. Raymond @ 2019-11-08 13:43 ` Richard Earnshaw (lists) 2019-11-09 6:01 ` Eric S. Raymond 0 siblings, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-08 13:43 UTC (permalink / raw) To: esr, Jeff Law; +Cc: GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-08 13:43 ` Richard Earnshaw (lists) @ 2019-11-09 6:01 ` Eric S. Raymond 2019-11-18 15:32 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Eric S. Raymond @ 2019-11-09 6:01 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: Jeff Law, GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-09 6:01 ` Eric S. Raymond @ 2019-11-18 15:32 ` Richard Earnshaw (lists) 2019-11-18 15:55 ` Segher Boessenkool 0 siblings, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 15:32 UTC (permalink / raw) To: esr; +Cc: Jeff Law, GCC Development [-- 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 15:32 ` Richard Earnshaw (lists) @ 2019-11-18 15:55 ` Segher Boessenkool 2019-11-18 16:48 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Segher Boessenkool @ 2019-11-18 15:55 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: esr, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 15:55 ` Segher Boessenkool @ 2019-11-18 16:48 ` Richard Earnshaw (lists) 2019-11-18 17:11 ` Segher Boessenkool 0 siblings, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 16:48 UTC (permalink / raw) To: Segher Boessenkool; +Cc: esr, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 16:48 ` Richard Earnshaw (lists) @ 2019-11-18 17:11 ` Segher Boessenkool [not found] ` <8c32c288-e9e6-b01b-7911-3f186116da85@gmail.com> 2019-11-18 17:38 ` Richard Earnshaw (lists) 0 siblings, 2 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-18 17:11 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: esr, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
[parent not found: <8c32c288-e9e6-b01b-7911-3f186116da85@gmail.com>]
* Re: Commit messages and the move to git [not found] ` <8c32c288-e9e6-b01b-7911-3f186116da85@gmail.com> @ 2019-11-18 17:24 ` Nicholas Krause 2019-11-18 17:26 ` Nicholas Krause 0 siblings, 1 reply; 139+ messages in thread From: Nicholas Krause @ 2019-11-18 17:24 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Richard.Earnshaw, esr, law, gcc 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 17:24 ` Nicholas Krause @ 2019-11-18 17:26 ` Nicholas Krause 2019-11-18 17:46 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Nicholas Krause @ 2019-11-18 17:26 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Richard.Earnshaw, esr, law, gcc 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 17:26 ` Nicholas Krause @ 2019-11-18 17:46 ` Richard Earnshaw (lists) 2019-11-18 17:49 ` Richard Earnshaw (lists) 2019-11-18 17:55 ` Nicholas Krause 0 siblings, 2 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 17:46 UTC (permalink / raw) To: Nicholas Krause, Segher Boessenkool; +Cc: esr, law, gcc 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 17:46 ` Richard Earnshaw (lists) @ 2019-11-18 17:49 ` Richard Earnshaw (lists) 2019-11-18 17:55 ` Nicholas Krause 1 sibling, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 17:49 UTC (permalink / raw) To: Nicholas Krause, Segher Boessenkool; +Cc: esr, law, gcc 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 17:46 ` Richard Earnshaw (lists) 2019-11-18 17:49 ` Richard Earnshaw (lists) @ 2019-11-18 17:55 ` Nicholas Krause 2019-11-18 18:05 ` Richard Earnshaw (lists) 1 sibling, 1 reply; 139+ messages in thread From: Nicholas Krause @ 2019-11-18 17:55 UTC (permalink / raw) To: Richard Earnshaw (lists), Segher Boessenkool; +Cc: esr, law, gcc 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 17:55 ` Nicholas Krause @ 2019-11-18 18:05 ` Richard Earnshaw (lists) 2019-11-18 18:24 ` Joseph Myers 2019-11-19 11:25 ` Eric S. Raymond 0 siblings, 2 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 18:05 UTC (permalink / raw) To: Nicholas Krause, Segher Boessenkool; +Cc: esr, law, gcc 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 18:05 ` Richard Earnshaw (lists) @ 2019-11-18 18:24 ` Joseph Myers 2019-11-19 11:26 ` Eric S. Raymond 2019-11-19 11:25 ` Eric S. Raymond 1 sibling, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-11-18 18:24 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Nicholas Krause, Segher Boessenkool, esr, law, gcc 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 18:24 ` Joseph Myers @ 2019-11-19 11:26 ` Eric S. Raymond 0 siblings, 0 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-11-19 11:26 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Nicholas Krause, Segher Boessenkool, law, gcc 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 18:05 ` Richard Earnshaw (lists) 2019-11-18 18:24 ` Joseph Myers @ 2019-11-19 11:25 ` Eric S. Raymond 2019-11-19 11:46 ` Richard Earnshaw (lists) 1 sibling, 1 reply; 139+ messages in thread From: Eric S. Raymond @ 2019-11-19 11:25 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: Nicholas Krause, Segher Boessenkool, law, gcc 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 11:25 ` Eric S. Raymond @ 2019-11-19 11:46 ` Richard Earnshaw (lists) 2019-11-19 19:32 ` Eric S. Raymond 2019-11-19 19:43 ` Richard Earnshaw (lists) 0 siblings, 2 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-19 11:46 UTC (permalink / raw) To: esr; +Cc: Nicholas Krause, Segher Boessenkool, law, gcc 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 11:46 ` Richard Earnshaw (lists) @ 2019-11-19 19:32 ` Eric S. Raymond 2019-11-19 19:47 ` Richard Earnshaw (lists) 2019-11-19 19:43 ` Richard Earnshaw (lists) 1 sibling, 1 reply; 139+ messages in thread From: Eric S. Raymond @ 2019-11-19 19:32 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: Nicholas Krause, Segher Boessenkool, law, gcc 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 19:32 ` Eric S. Raymond @ 2019-11-19 19:47 ` Richard Earnshaw (lists) 2019-11-19 19:49 ` Richard Earnshaw (lists) 2019-11-19 22:14 ` Eric S. Raymond 0 siblings, 2 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-19 19:47 UTC (permalink / raw) To: esr; +Cc: Nicholas Krause, Segher Boessenkool, law, gcc 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 19:47 ` Richard Earnshaw (lists) @ 2019-11-19 19:49 ` Richard Earnshaw (lists) 2019-11-19 22:14 ` Eric S. Raymond 1 sibling, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-19 19:49 UTC (permalink / raw) To: esr; +Cc: Nicholas Krause, Segher Boessenkool, law, gcc 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 19:47 ` Richard Earnshaw (lists) 2019-11-19 19:49 ` Richard Earnshaw (lists) @ 2019-11-19 22:14 ` Eric S. Raymond 2019-11-19 22:19 ` Richard Earnshaw (lists) 2019-11-21 16:41 ` Joseph Myers 1 sibling, 2 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-11-19 22:14 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: Nicholas Krause, Segher Boessenkool, law, gcc 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 22:14 ` Eric S. Raymond @ 2019-11-19 22:19 ` Richard Earnshaw (lists) 2019-11-21 16:41 ` Joseph Myers 1 sibling, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-19 22:19 UTC (permalink / raw) To: esr; +Cc: Nicholas Krause, Segher Boessenkool, law, gcc 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 22:14 ` Eric S. Raymond 2019-11-19 22:19 ` Richard Earnshaw (lists) @ 2019-11-21 16:41 ` Joseph Myers 2019-11-21 16:52 ` Richard Earnshaw (lists) ` (2 more replies) 1 sibling, 3 replies; 139+ messages in thread From: Joseph Myers @ 2019-11-21 16:41 UTC (permalink / raw) To: Eric S. Raymond Cc: Richard Earnshaw (lists), Nicholas Krause, Segher Boessenkool, law, gcc 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-21 16:41 ` Joseph Myers @ 2019-11-21 16:52 ` Richard Earnshaw (lists) 2019-11-21 18:11 ` Eric S. Raymond 2019-11-21 18:09 ` Eric S. Raymond 2019-11-21 19:22 ` Richard Earnshaw (lists) 2 siblings, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-21 16:52 UTC (permalink / raw) To: Joseph Myers, Eric S. Raymond Cc: Nicholas Krause, Segher Boessenkool, law, gcc 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. > ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-21 16:52 ` Richard Earnshaw (lists) @ 2019-11-21 18:11 ` Eric S. Raymond 0 siblings, 0 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-11-21 18:11 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Joseph Myers, Nicholas Krause, Segher Boessenkool, law, gcc 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-21 16:41 ` Joseph Myers 2019-11-21 16:52 ` Richard Earnshaw (lists) @ 2019-11-21 18:09 ` Eric S. Raymond 2019-11-21 19:22 ` Richard Earnshaw (lists) 2 siblings, 0 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-11-21 18:09 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Nicholas Krause, Segher Boessenkool, law, gcc 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-21 16:41 ` Joseph Myers 2019-11-21 16:52 ` Richard Earnshaw (lists) 2019-11-21 18:09 ` Eric S. Raymond @ 2019-11-21 19:22 ` Richard Earnshaw (lists) 2 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-21 19:22 UTC (permalink / raw) To: Eric S. Raymond Cc: Joseph Myers, Nicholas Krause, Segher Boessenkool, law, gcc 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 11:46 ` Richard Earnshaw (lists) 2019-11-19 19:32 ` Eric S. Raymond @ 2019-11-19 19:43 ` Richard Earnshaw (lists) 2019-11-19 22:08 ` Eric S. Raymond 1 sibling, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-19 19:43 UTC (permalink / raw) To: esr; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 19:43 ` Richard Earnshaw (lists) @ 2019-11-19 22:08 ` Eric S. Raymond 0 siblings, 0 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-11-19 22:08 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: gcc 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 17:11 ` Segher Boessenkool [not found] ` <8c32c288-e9e6-b01b-7911-3f186116da85@gmail.com> @ 2019-11-18 17:38 ` Richard Earnshaw (lists) 2019-11-18 18:53 ` Segher Boessenkool 2019-12-18 23:43 ` Joseph Myers 1 sibling, 2 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 17:38 UTC (permalink / raw) To: Segher Boessenkool; +Cc: esr, Jeff Law, GCC Development [-- 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 --] ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 17:38 ` Richard Earnshaw (lists) @ 2019-11-18 18:53 ` Segher Boessenkool 2019-11-18 19:14 ` Richard Earnshaw (lists) 2019-11-18 19:21 ` Richard Earnshaw (lists) 2019-12-18 23:43 ` Joseph Myers 1 sibling, 2 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-18 18:53 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: esr, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 18:53 ` Segher Boessenkool @ 2019-11-18 19:14 ` Richard Earnshaw (lists) 2019-11-18 19:21 ` Richard Earnshaw (lists) 1 sibling, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 19:14 UTC (permalink / raw) To: Segher Boessenkool; +Cc: esr, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 18:53 ` Segher Boessenkool 2019-11-18 19:14 ` Richard Earnshaw (lists) @ 2019-11-18 19:21 ` Richard Earnshaw (lists) 2019-11-18 19:44 ` Segher Boessenkool 1 sibling, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 19:21 UTC (permalink / raw) To: Segher Boessenkool; +Cc: esr, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 19:21 ` Richard Earnshaw (lists) @ 2019-11-18 19:44 ` Segher Boessenkool 2019-11-18 20:53 ` Jason Merrill 0 siblings, 1 reply; 139+ messages in thread From: Segher Boessenkool @ 2019-11-18 19:44 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: esr, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 19:44 ` Segher Boessenkool @ 2019-11-18 20:53 ` Jason Merrill 2019-11-18 21:38 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Jason Merrill @ 2019-11-18 20:53 UTC (permalink / raw) To: Segher Boessenkool Cc: Richard Earnshaw (lists), Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 20:53 ` Jason Merrill @ 2019-11-18 21:38 ` Richard Earnshaw (lists) 2019-11-19 14:57 ` Jason Merrill 0 siblings, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-18 21:38 UTC (permalink / raw) To: Jason Merrill, Segher Boessenkool; +Cc: Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 21:38 ` Richard Earnshaw (lists) @ 2019-11-19 14:57 ` Jason Merrill 2019-11-19 16:31 ` Segher Boessenkool 2019-12-02 10:54 ` Richard Earnshaw (lists) 0 siblings, 2 replies; 139+ messages in thread From: Jason Merrill @ 2019-11-19 14:57 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 14:57 ` Jason Merrill @ 2019-11-19 16:31 ` Segher Boessenkool 2019-11-19 16:47 ` Jonathan Wakely ` (2 more replies) 2019-12-02 10:54 ` Richard Earnshaw (lists) 1 sibling, 3 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-19 16:31 UTC (permalink / raw) To: Jason Merrill Cc: Richard Earnshaw (lists), Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 16:31 ` Segher Boessenkool @ 2019-11-19 16:47 ` Jonathan Wakely 2019-11-19 16:48 ` Jason Merrill 2019-11-19 16:49 ` Richard Earnshaw (lists) 2 siblings, 0 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-11-19 16:47 UTC (permalink / raw) To: Segher Boessenkool Cc: Jason Merrill, Richard Earnshaw (lists), Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 16:31 ` Segher Boessenkool 2019-11-19 16:47 ` Jonathan Wakely @ 2019-11-19 16:48 ` Jason Merrill 2019-11-19 19:36 ` Eric S. Raymond 2019-11-19 16:49 ` Richard Earnshaw (lists) 2 siblings, 1 reply; 139+ messages in thread From: Jason Merrill @ 2019-11-19 16:48 UTC (permalink / raw) To: Segher Boessenkool Cc: Richard Earnshaw (lists), Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 16:48 ` Jason Merrill @ 2019-11-19 19:36 ` Eric S. Raymond 2019-11-19 23:29 ` Segher Boessenkool 0 siblings, 1 reply; 139+ messages in thread From: Eric S. Raymond @ 2019-11-19 19:36 UTC (permalink / raw) To: Jason Merrill Cc: Segher Boessenkool, Richard Earnshaw (lists), Jeff Law, GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 19:36 ` Eric S. Raymond @ 2019-11-19 23:29 ` Segher Boessenkool 2019-11-19 23:44 ` Joseph Myers 2019-11-20 8:58 ` Jonathan Wakely 0 siblings, 2 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-19 23:29 UTC (permalink / raw) To: Eric S. Raymond Cc: Jason Merrill, Richard Earnshaw (lists), Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 23:29 ` Segher Boessenkool @ 2019-11-19 23:44 ` Joseph Myers 2019-11-19 23:51 ` Nicholas Krause ` (2 more replies) 2019-11-20 8:58 ` Jonathan Wakely 1 sibling, 3 replies; 139+ messages in thread From: Joseph Myers @ 2019-11-19 23:44 UTC (permalink / raw) To: Segher Boessenkool Cc: Eric S. Raymond, Jason Merrill, Richard Earnshaw (lists), Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 23:44 ` Joseph Myers @ 2019-11-19 23:51 ` Nicholas Krause 2019-11-20 8:55 ` Jonathan Wakely 2019-11-20 14:50 ` Szabolcs Nagy 2019-11-20 17:30 ` Richard Earnshaw (lists) 2 siblings, 1 reply; 139+ messages in thread From: Nicholas Krause @ 2019-11-19 23:51 UTC (permalink / raw) To: Joseph Myers, Segher Boessenkool Cc: Eric S. Raymond, Jason Merrill, Richard Earnshaw (lists), Jeff Law, GCC Development 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 > ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 23:51 ` Nicholas Krause @ 2019-11-20 8:55 ` Jonathan Wakely 0 siblings, 0 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-11-20 8:55 UTC (permalink / raw) To: Nicholas Krause Cc: Joseph Myers, Segher Boessenkool, Eric S. Raymond, Jason Merrill, Richard Earnshaw (lists), Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 23:44 ` Joseph Myers 2019-11-19 23:51 ` Nicholas Krause @ 2019-11-20 14:50 ` Szabolcs Nagy 2019-11-20 17:30 ` Richard Earnshaw (lists) 2 siblings, 0 replies; 139+ messages in thread From: Szabolcs Nagy @ 2019-11-20 14:50 UTC (permalink / raw) To: Joseph Myers, Segher Boessenkool Cc: nd, Eric S. Raymond, Jason Merrill, Richard Earnshaw, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 23:44 ` Joseph Myers 2019-11-19 23:51 ` Nicholas Krause 2019-11-20 14:50 ` Szabolcs Nagy @ 2019-11-20 17:30 ` Richard Earnshaw (lists) 2 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-20 17:30 UTC (permalink / raw) To: Joseph Myers, Segher Boessenkool Cc: Eric S. Raymond, Jason Merrill, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 23:29 ` Segher Boessenkool 2019-11-19 23:44 ` Joseph Myers @ 2019-11-20 8:58 ` Jonathan Wakely 2019-11-20 11:27 ` Segher Boessenkool 1 sibling, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-11-20 8:58 UTC (permalink / raw) To: Segher Boessenkool Cc: Eric S. Raymond, Jason Merrill, Richard Earnshaw (lists), Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-20 8:58 ` Jonathan Wakely @ 2019-11-20 11:27 ` Segher Boessenkool 2019-11-20 11:30 ` Richard Earnshaw (lists) 2019-11-20 14:25 ` Jason Merrill 0 siblings, 2 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-20 11:27 UTC (permalink / raw) To: Jonathan Wakely Cc: Eric S. Raymond, Jason Merrill, Richard Earnshaw (lists), Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-20 11:27 ` Segher Boessenkool @ 2019-11-20 11:30 ` Richard Earnshaw (lists) 2019-11-20 11:42 ` Segher Boessenkool 2019-11-20 14:25 ` Jason Merrill 1 sibling, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-20 11:30 UTC (permalink / raw) To: Segher Boessenkool, Jonathan Wakely Cc: Eric S. Raymond, Jason Merrill, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-20 11:30 ` Richard Earnshaw (lists) @ 2019-11-20 11:42 ` Segher Boessenkool 0 siblings, 0 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-20 11:42 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jonathan Wakely, Eric S. Raymond, Jason Merrill, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-20 11:27 ` Segher Boessenkool 2019-11-20 11:30 ` Richard Earnshaw (lists) @ 2019-11-20 14:25 ` Jason Merrill 2019-11-20 16:01 ` Segher Boessenkool 1 sibling, 1 reply; 139+ messages in thread From: Jason Merrill @ 2019-11-20 14:25 UTC (permalink / raw) To: Segher Boessenkool Cc: Jonathan Wakely, Eric S. Raymond, Richard Earnshaw (lists), Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-20 14:25 ` Jason Merrill @ 2019-11-20 16:01 ` Segher Boessenkool 0 siblings, 0 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-20 16:01 UTC (permalink / raw) To: Jason Merrill Cc: Jonathan Wakely, Eric S. Raymond, Richard Earnshaw (lists), Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 16:31 ` Segher Boessenkool 2019-11-19 16:47 ` Jonathan Wakely 2019-11-19 16:48 ` Jason Merrill @ 2019-11-19 16:49 ` Richard Earnshaw (lists) 2 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-19 16:49 UTC (permalink / raw) To: Segher Boessenkool, Jason Merrill; +Cc: Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-19 14:57 ` Jason Merrill 2019-11-19 16:31 ` Segher Boessenkool @ 2019-12-02 10:54 ` Richard Earnshaw (lists) 2019-12-02 15:35 ` Segher Boessenkool 2019-12-04 23:52 ` Richard Earnshaw (lists) 1 sibling, 2 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-02 10:54 UTC (permalink / raw) To: Jason Merrill; +Cc: Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development [-- 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() ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 10:54 ` Richard Earnshaw (lists) @ 2019-12-02 15:35 ` Segher Boessenkool 2019-12-02 16:19 ` Richard Earnshaw (lists) 2019-12-04 23:52 ` Richard Earnshaw (lists) 1 sibling, 1 reply; 139+ messages in thread From: Segher Boessenkool @ 2019-12-02 15:35 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 15:35 ` Segher Boessenkool @ 2019-12-02 16:19 ` Richard Earnshaw (lists) 2019-12-02 17:25 ` Segher Boessenkool 2019-12-02 20:22 ` Richard Sandiford 0 siblings, 2 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-02 16:19 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 16:19 ` Richard Earnshaw (lists) @ 2019-12-02 17:25 ` Segher Boessenkool 2019-12-02 17:47 ` Richard Earnshaw (lists) 2019-12-02 20:24 ` Joseph Myers 2019-12-02 20:22 ` Richard Sandiford 1 sibling, 2 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-12-02 17:25 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 17:25 ` Segher Boessenkool @ 2019-12-02 17:47 ` Richard Earnshaw (lists) 2019-12-02 18:00 ` Segher Boessenkool 2019-12-02 20:24 ` Joseph Myers 1 sibling, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-02 17:47 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 17:47 ` Richard Earnshaw (lists) @ 2019-12-02 18:00 ` Segher Boessenkool 2019-12-02 18:11 ` Richard Earnshaw (lists) 2019-12-02 18:17 ` Eric S. Raymond 0 siblings, 2 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-12-02 18:00 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 18:00 ` Segher Boessenkool @ 2019-12-02 18:11 ` Richard Earnshaw (lists) 2019-12-02 18:17 ` Eric S. Raymond 1 sibling, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-02 18:11 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 18:00 ` Segher Boessenkool 2019-12-02 18:11 ` Richard Earnshaw (lists) @ 2019-12-02 18:17 ` Eric S. Raymond 1 sibling, 0 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-12-02 18:17 UTC (permalink / raw) To: Segher Boessenkool Cc: Richard Earnshaw (lists), Jason Merrill, Jeff Law, GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 17:25 ` Segher Boessenkool 2019-12-02 17:47 ` Richard Earnshaw (lists) @ 2019-12-02 20:24 ` Joseph Myers 2019-12-03 0:48 ` Segher Boessenkool 1 sibling, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-02 20:24 UTC (permalink / raw) To: Segher Boessenkool Cc: Richard Earnshaw (lists), Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 20:24 ` Joseph Myers @ 2019-12-03 0:48 ` Segher Boessenkool 2019-12-03 9:44 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Segher Boessenkool @ 2019-12-03 0:48 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-03 0:48 ` Segher Boessenkool @ 2019-12-03 9:44 ` Richard Earnshaw (lists) 2019-12-03 10:12 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-03 9:44 UTC (permalink / raw) To: Segher Boessenkool, Joseph Myers Cc: Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-03 9:44 ` Richard Earnshaw (lists) @ 2019-12-03 10:12 ` Richard Earnshaw (lists) 0 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-03 10:12 UTC (permalink / raw) To: Segher Boessenkool, Joseph Myers Cc: Jason Merrill, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 16:19 ` Richard Earnshaw (lists) 2019-12-02 17:25 ` Segher Boessenkool @ 2019-12-02 20:22 ` Richard Sandiford 1 sibling, 0 replies; 139+ messages in thread From: Richard Sandiford @ 2019-12-02 20:22 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Segher Boessenkool, Jason Merrill, Eric Raymond, Jeff Law, GCC Development "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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-02 10:54 ` Richard Earnshaw (lists) 2019-12-02 15:35 ` Segher Boessenkool @ 2019-12-04 23:52 ` Richard Earnshaw (lists) 2019-12-05 10:26 ` Jonathan Wakely 1 sibling, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-04 23:52 UTC (permalink / raw) To: Jason Merrill; +Cc: Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-04 23:52 ` Richard Earnshaw (lists) @ 2019-12-05 10:26 ` Jonathan Wakely 2019-12-05 10:32 ` Jonathan Wakely 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-05 10:26 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jason Merrill, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 10:26 ` Jonathan Wakely @ 2019-12-05 10:32 ` Jonathan Wakely 2019-12-05 10:36 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-05 10:32 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jason Merrill, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 10:32 ` Jonathan Wakely @ 2019-12-05 10:36 ` Richard Earnshaw (lists) 2019-12-05 10:41 ` Jonathan Wakely ` (2 more replies) 0 siblings, 3 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-05 10:36 UTC (permalink / raw) To: Jonathan Wakely Cc: Jason Merrill, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 10:36 ` Richard Earnshaw (lists) @ 2019-12-05 10:41 ` Jonathan Wakely 2019-12-05 10:54 ` Jonathan Wakely 2019-12-05 13:18 ` Joseph Myers 2019-12-05 15:33 ` Eric S. Raymond 2 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-05 10:41 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jason Merrill, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 10:41 ` Jonathan Wakely @ 2019-12-05 10:54 ` Jonathan Wakely 0 siblings, 0 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-12-05 10:54 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jason Merrill, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 10:36 ` Richard Earnshaw (lists) 2019-12-05 10:41 ` Jonathan Wakely @ 2019-12-05 13:18 ` Joseph Myers 2019-12-05 17:10 ` Eric S. Raymond 2019-12-05 15:33 ` Eric S. Raymond 2 siblings, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-05 13:18 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jonathan Wakely, Jason Merrill, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 13:18 ` Joseph Myers @ 2019-12-05 17:10 ` Eric S. Raymond 2019-12-05 17:22 ` Joseph Myers 0 siblings, 1 reply; 139+ messages in thread From: Eric S. Raymond @ 2019-12-05 17:10 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Jonathan Wakely, Jason Merrill, Segher Boessenkool, Jeff Law, GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 17:10 ` Eric S. Raymond @ 2019-12-05 17:22 ` Joseph Myers 2019-12-05 17:45 ` Eric S. Raymond 0 siblings, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-05 17:22 UTC (permalink / raw) To: Eric S. Raymond Cc: Richard Earnshaw (lists), Jonathan Wakely, Jason Merrill, Segher Boessenkool, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 17:22 ` Joseph Myers @ 2019-12-05 17:45 ` Eric S. Raymond 2019-12-05 20:14 ` Joseph Myers 0 siblings, 1 reply; 139+ messages in thread From: Eric S. Raymond @ 2019-12-05 17:45 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Jonathan Wakely, Jason Merrill, Segher Boessenkool, Jeff Law, GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 17:45 ` Eric S. Raymond @ 2019-12-05 20:14 ` Joseph Myers 2019-12-05 20:46 ` Joseph Myers 2019-12-05 21:13 ` Eric S. Raymond 0 siblings, 2 replies; 139+ messages in thread From: Joseph Myers @ 2019-12-05 20:14 UTC (permalink / raw) To: Eric S. Raymond Cc: Richard Earnshaw (lists), Jonathan Wakely, Jason Merrill, Segher Boessenkool, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 20:14 ` Joseph Myers @ 2019-12-05 20:46 ` Joseph Myers 2019-12-05 21:14 ` Eric S. Raymond 2019-12-05 21:13 ` Eric S. Raymond 1 sibling, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-05 20:46 UTC (permalink / raw) To: Eric S. Raymond Cc: Richard Earnshaw (lists), Jonathan Wakely, Jason Merrill, Segher Boessenkool, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 20:46 ` Joseph Myers @ 2019-12-05 21:14 ` Eric S. Raymond 0 siblings, 0 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-12-05 21:14 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Jonathan Wakely, Jason Merrill, Segher Boessenkool, Jeff Law, GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 20:14 ` Joseph Myers 2019-12-05 20:46 ` Joseph Myers @ 2019-12-05 21:13 ` Eric S. Raymond 1 sibling, 0 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-12-05 21:13 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Jonathan Wakely, Jason Merrill, Segher Boessenkool, Jeff Law, GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-05 10:36 ` Richard Earnshaw (lists) 2019-12-05 10:41 ` Jonathan Wakely 2019-12-05 13:18 ` Joseph Myers @ 2019-12-05 15:33 ` Eric S. Raymond 2 siblings, 0 replies; 139+ messages in thread From: Eric S. Raymond @ 2019-12-05 15:33 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jonathan Wakely, Jason Merrill, Segher Boessenkool, Jeff Law, GCC Development 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> ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-18 17:38 ` Richard Earnshaw (lists) 2019-11-18 18:53 ` Segher Boessenkool @ 2019-12-18 23:43 ` Joseph Myers 2019-12-19 0:01 ` Joseph Myers 1 sibling, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-18 23:43 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Segher Boessenkool, esr, Jeff Law, GCC Development [-- 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]) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-18 23:43 ` Joseph Myers @ 2019-12-19 0:01 ` Joseph Myers 2019-12-19 9:27 ` Jonathan Wakely 2019-12-19 11:16 ` Jakub Jelinek 0 siblings, 2 replies; 139+ messages in thread From: Joseph Myers @ 2019-12-19 0:01 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Segher Boessenkool, esr, Jeff Law, GCC Development [-- 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]) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 0:01 ` Joseph Myers @ 2019-12-19 9:27 ` Jonathan Wakely 2019-12-19 11:05 ` Jonathan Wakely 2019-12-19 11:50 ` Richard Earnshaw (lists) 2019-12-19 11:16 ` Jakub Jelinek 1 sibling, 2 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 9:27 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 9:27 ` Jonathan Wakely @ 2019-12-19 11:05 ` Jonathan Wakely 2019-12-19 11:50 ` Richard Earnshaw (lists) 1 sibling, 0 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 11:05 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 9:27 ` Jonathan Wakely 2019-12-19 11:05 ` Jonathan Wakely @ 2019-12-19 11:50 ` Richard Earnshaw (lists) 2019-12-19 11:58 ` Richard Earnshaw (lists) ` (2 more replies) 1 sibling, 3 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-19 11:50 UTC (permalink / raw) To: Jonathan Wakely, Joseph Myers Cc: Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 11:50 ` Richard Earnshaw (lists) @ 2019-12-19 11:58 ` Richard Earnshaw (lists) 2019-12-19 12:23 ` Jonathan Wakely 2019-12-19 14:29 ` Joseph Myers 2 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-19 11:58 UTC (permalink / raw) To: Jonathan Wakely, Joseph Myers Cc: Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 11:50 ` Richard Earnshaw (lists) 2019-12-19 11:58 ` Richard Earnshaw (lists) @ 2019-12-19 12:23 ` Jonathan Wakely 2019-12-19 12:33 ` Richard Earnshaw (lists) 2019-12-19 14:29 ` Joseph Myers 2 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 12:23 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Joseph Myers, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 12:23 ` Jonathan Wakely @ 2019-12-19 12:33 ` Richard Earnshaw (lists) 2019-12-19 12:35 ` Jonathan Wakely 0 siblings, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-19 12:33 UTC (permalink / raw) To: Jonathan Wakely Cc: Joseph Myers, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 12:33 ` Richard Earnshaw (lists) @ 2019-12-19 12:35 ` Jonathan Wakely 2019-12-19 12:42 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 12:35 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Joseph Myers, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 12:35 ` Jonathan Wakely @ 2019-12-19 12:42 ` Richard Earnshaw (lists) 2019-12-19 13:34 ` Jonathan Wakely 0 siblings, 1 reply; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-19 12:42 UTC (permalink / raw) To: Jonathan Wakely Cc: Joseph Myers, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 12:42 ` Richard Earnshaw (lists) @ 2019-12-19 13:34 ` Jonathan Wakely 2019-12-19 16:00 ` Joseph Myers 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 13:34 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Joseph Myers, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 13:34 ` Jonathan Wakely @ 2019-12-19 16:00 ` Joseph Myers 2019-12-19 16:06 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-19 16:00 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 16:00 ` Joseph Myers @ 2019-12-19 16:06 ` Richard Earnshaw (lists) 0 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-19 16:06 UTC (permalink / raw) To: Joseph Myers, Jonathan Wakely Cc: Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 11:50 ` Richard Earnshaw (lists) 2019-12-19 11:58 ` Richard Earnshaw (lists) 2019-12-19 12:23 ` Jonathan Wakely @ 2019-12-19 14:29 ` Joseph Myers 2019-12-19 15:17 ` Jonathan Wakely 2 siblings, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-19 14:29 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jonathan Wakely, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 14:29 ` Joseph Myers @ 2019-12-19 15:17 ` Jonathan Wakely 2019-12-19 15:20 ` Richard Earnshaw (lists) 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 15:17 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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). ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 15:17 ` Jonathan Wakely @ 2019-12-19 15:20 ` Richard Earnshaw (lists) 2019-12-19 15:44 ` Jonathan Wakely 2019-12-19 15:49 ` Joseph Myers 0 siblings, 2 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-19 15:20 UTC (permalink / raw) To: Jonathan Wakely, Joseph Myers Cc: Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 15:20 ` Richard Earnshaw (lists) @ 2019-12-19 15:44 ` Jonathan Wakely 2019-12-19 15:47 ` Joseph Myers 2019-12-19 15:48 ` Richard Earnshaw (lists) 2019-12-19 15:49 ` Joseph Myers 1 sibling, 2 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 15:44 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Joseph Myers, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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]) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 15:44 ` Jonathan Wakely @ 2019-12-19 15:47 ` Joseph Myers 2019-12-19 15:48 ` Jonathan Wakely 2019-12-19 15:48 ` Richard Earnshaw (lists) 1 sibling, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-19 15:47 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 15:47 ` Joseph Myers @ 2019-12-19 15:48 ` Jonathan Wakely 0 siblings, 0 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 15:48 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 15:44 ` Jonathan Wakely 2019-12-19 15:47 ` Joseph Myers @ 2019-12-19 15:48 ` Richard Earnshaw (lists) 1 sibling, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-19 15:48 UTC (permalink / raw) To: Jonathan Wakely Cc: Joseph Myers, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 15:20 ` Richard Earnshaw (lists) 2019-12-19 15:44 ` Jonathan Wakely @ 2019-12-19 15:49 ` Joseph Myers 2019-12-19 16:27 ` Jonathan Wakely 1 sibling, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-19 15:49 UTC (permalink / raw) To: Richard Earnshaw (lists) Cc: Jonathan Wakely, Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 15:49 ` Joseph Myers @ 2019-12-19 16:27 ` Jonathan Wakely 2019-12-19 16:28 ` Jonathan Wakely ` (2 more replies) 0 siblings, 3 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 16:27 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development [-- 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]) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 16:27 ` Jonathan Wakely @ 2019-12-19 16:28 ` Jonathan Wakely 2019-12-19 16:33 ` Joseph Myers 2019-12-20 20:30 ` Joseph Myers 2 siblings, 0 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 16:28 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 16:27 ` Jonathan Wakely 2019-12-19 16:28 ` Jonathan Wakely @ 2019-12-19 16:33 ` Joseph Myers 2019-12-19 16:39 ` Jonathan Wakely 2019-12-20 20:30 ` Joseph Myers 2 siblings, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-19 16:33 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 16:33 ` Joseph Myers @ 2019-12-19 16:39 ` Jonathan Wakely 2019-12-19 16:43 ` Joseph Myers 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-19 16:39 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 16:39 ` Jonathan Wakely @ 2019-12-19 16:43 ` Joseph Myers 0 siblings, 0 replies; 139+ messages in thread From: Joseph Myers @ 2019-12-19 16:43 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 16:27 ` Jonathan Wakely 2019-12-19 16:28 ` Jonathan Wakely 2019-12-19 16:33 ` Joseph Myers @ 2019-12-20 20:30 ` Joseph Myers 2019-12-20 21:30 ` Jonathan Wakely 2 siblings, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-20 20:30 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development [-- 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]) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-20 20:30 ` Joseph Myers @ 2019-12-20 21:30 ` Jonathan Wakely 2019-12-20 21:41 ` Joseph Myers 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-20 21:30 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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]) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-20 21:30 ` Jonathan Wakely @ 2019-12-20 21:41 ` Joseph Myers 2019-12-20 22:11 ` Jonathan Wakely 0 siblings, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-20 21:41 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-20 21:41 ` Joseph Myers @ 2019-12-20 22:11 ` Jonathan Wakely 2019-12-20 22:58 ` Joseph Myers 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-20 22:11 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development [-- 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]) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-20 22:11 ` Jonathan Wakely @ 2019-12-20 22:58 ` Joseph Myers 2019-12-20 23:23 ` Jonathan Wakely 0 siblings, 1 reply; 139+ messages in thread From: Joseph Myers @ 2019-12-20 22:58 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-20 22:58 ` Joseph Myers @ 2019-12-20 23:23 ` Jonathan Wakely 2019-12-20 23:53 ` Joseph Myers 0 siblings, 1 reply; 139+ messages in thread From: Jonathan Wakely @ 2019-12-20 23:23 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-20 23:23 ` Jonathan Wakely @ 2019-12-20 23:53 ` Joseph Myers 0 siblings, 0 replies; 139+ messages in thread From: Joseph Myers @ 2019-12-20 23:53 UTC (permalink / raw) To: Jonathan Wakely Cc: Richard Earnshaw (lists), Segher Boessenkool, Eric Raymond, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 0:01 ` Joseph Myers 2019-12-19 9:27 ` Jonathan Wakely @ 2019-12-19 11:16 ` Jakub Jelinek 2019-12-19 15:05 ` Richard Earnshaw (lists) 1 sibling, 1 reply; 139+ messages in thread From: Jakub Jelinek @ 2019-12-19 11:16 UTC (permalink / raw) To: Joseph Myers Cc: Richard Earnshaw (lists), Segher Boessenkool, esr, Jeff Law, GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-12-19 11:16 ` Jakub Jelinek @ 2019-12-19 15:05 ` Richard Earnshaw (lists) 0 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-12-19 15:05 UTC (permalink / raw) To: Jakub Jelinek, Joseph Myers Cc: Segher Boessenkool, esr, Jeff Law, GCC Development 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]. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 10:29 Commit messages and the move to git Richard Earnshaw (lists) ` (2 preceding siblings ...) 2019-11-04 16:04 ` Jeff Law @ 2019-11-04 16:19 ` Jonathan Wakely 2019-11-04 16:35 ` Richard Earnshaw (lists) 2019-11-04 17:33 ` Segher Boessenkool 2019-11-05 2:51 ` Kewen.Lin 4 siblings, 2 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-11-04 16:19 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 16:19 ` Jonathan Wakely @ 2019-11-04 16:35 ` Richard Earnshaw (lists) 2019-11-04 17:33 ` Segher Boessenkool 1 sibling, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-04 16:35 UTC (permalink / raw) To: Jonathan Wakely; +Cc: GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 16:19 ` Jonathan Wakely 2019-11-04 16:35 ` Richard Earnshaw (lists) @ 2019-11-04 17:33 ` Segher Boessenkool 2019-11-04 17:42 ` Joseph Myers 1 sibling, 1 reply; 139+ messages in thread From: Segher Boessenkool @ 2019-11-04 17:33 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 17:33 ` Segher Boessenkool @ 2019-11-04 17:42 ` Joseph Myers 2019-11-04 17:50 ` Segher Boessenkool 2019-11-05 11:07 ` Jonathan Wakely 0 siblings, 2 replies; 139+ messages in thread From: Joseph Myers @ 2019-11-04 17:42 UTC (permalink / raw) To: Segher Boessenkool Cc: Jonathan Wakely, Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 17:42 ` Joseph Myers @ 2019-11-04 17:50 ` Segher Boessenkool 2019-11-05 11:07 ` Jonathan Wakely 1 sibling, 0 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-04 17:50 UTC (permalink / raw) To: Joseph Myers; +Cc: Jonathan Wakely, Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 17:42 ` Joseph Myers 2019-11-04 17:50 ` Segher Boessenkool @ 2019-11-05 11:07 ` Jonathan Wakely 2019-11-05 11:28 ` Jason Merrill 2019-11-05 20:16 ` Segher Boessenkool 1 sibling, 2 replies; 139+ messages in thread From: Jonathan Wakely @ 2019-11-05 11:07 UTC (permalink / raw) To: Joseph Myers Cc: Segher Boessenkool, Richard Earnshaw (lists), GCC Development 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 :-) ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-05 11:07 ` Jonathan Wakely @ 2019-11-05 11:28 ` Jason Merrill 2019-11-05 14:12 ` Marek Polacek 2019-11-05 14:50 ` David Malcolm 2019-11-05 20:16 ` Segher Boessenkool 1 sibling, 2 replies; 139+ messages in thread From: Jason Merrill @ 2019-11-05 11:28 UTC (permalink / raw) To: Jonathan Wakely Cc: Joseph Myers, Segher Boessenkool, Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-05 11:28 ` Jason Merrill @ 2019-11-05 14:12 ` Marek Polacek 2019-11-05 21:40 ` Richard Earnshaw (lists) 2019-11-05 14:50 ` David Malcolm 1 sibling, 1 reply; 139+ messages in thread From: Marek Polacek @ 2019-11-05 14:12 UTC (permalink / raw) To: Jason Merrill Cc: Jonathan Wakely, Joseph Myers, Segher Boessenkool, Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-05 14:12 ` Marek Polacek @ 2019-11-05 21:40 ` Richard Earnshaw (lists) 0 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-05 21:40 UTC (permalink / raw) To: Marek Polacek, Jason Merrill Cc: Jonathan Wakely, Joseph Myers, Segher Boessenkool, GCC Development 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 > ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-05 11:28 ` Jason Merrill 2019-11-05 14:12 ` Marek Polacek @ 2019-11-05 14:50 ` David Malcolm 2019-11-05 22:08 ` Segher Boessenkool 1 sibling, 1 reply; 139+ messages in thread From: David Malcolm @ 2019-11-05 14:50 UTC (permalink / raw) To: Jason Merrill, Jonathan Wakely Cc: Joseph Myers, Segher Boessenkool, Richard Earnshaw (lists), GCC Development 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 > ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-05 14:50 ` David Malcolm @ 2019-11-05 22:08 ` Segher Boessenkool 0 siblings, 0 replies; 139+ messages in thread From: Segher Boessenkool @ 2019-11-05 22:08 UTC (permalink / raw) To: David Malcolm Cc: Jason Merrill, Jonathan Wakely, Joseph Myers, Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-05 11:07 ` Jonathan Wakely 2019-11-05 11:28 ` Jason Merrill @ 2019-11-05 20:16 ` Segher Boessenkool 2019-11-05 21:01 ` Iain Sandoe 1 sibling, 1 reply; 139+ messages in thread From: Segher Boessenkool @ 2019-11-05 20:16 UTC (permalink / raw) To: Jonathan Wakely; +Cc: Joseph Myers, Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-05 20:16 ` Segher Boessenkool @ 2019-11-05 21:01 ` Iain Sandoe 0 siblings, 0 replies; 139+ messages in thread From: Iain Sandoe @ 2019-11-05 21:01 UTC (permalink / raw) To: Segher Boessenkool Cc: Jonathan Wakely, Joseph Myers, Richard Earnshaw (lists), GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-04 10:29 Commit messages and the move to git Richard Earnshaw (lists) ` (3 preceding siblings ...) 2019-11-04 16:19 ` Jonathan Wakely @ 2019-11-05 2:51 ` Kewen.Lin 2019-11-05 21:42 ` Richard Earnshaw (lists) 4 siblings, 1 reply; 139+ messages in thread From: Kewen.Lin @ 2019-11-05 2:51 UTC (permalink / raw) To: Richard Earnshaw (lists); +Cc: GCC Development 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 ^ permalink raw reply [flat|nested] 139+ messages in thread
* Re: Commit messages and the move to git 2019-11-05 2:51 ` Kewen.Lin @ 2019-11-05 21:42 ` Richard Earnshaw (lists) 0 siblings, 0 replies; 139+ messages in thread From: Richard Earnshaw (lists) @ 2019-11-05 21:42 UTC (permalink / raw) To: Kewen.Lin; +Cc: GCC Development 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. ^ permalink raw reply [flat|nested] 139+ messages in thread
end of thread, other threads:[~2019-12-20 23:53 UTC | newest] Thread overview: 139+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-04 10:29 Commit messages and the move to git Richard Earnshaw (lists) 2019-11-04 12:11 ` Arnaud Charlet 2019-11-04 12:43 ` Martin Jambor 2019-11-04 17:43 ` Segher Boessenkool 2019-11-04 16:04 ` Jeff Law 2019-11-04 16:18 ` Richard Earnshaw (lists) 2019-11-05 15:48 ` Richard Earnshaw 2019-11-07 14:27 ` Eric S. Raymond 2019-11-08 13:43 ` Richard Earnshaw (lists) 2019-11-09 6:01 ` Eric S. Raymond 2019-11-18 15:32 ` Richard Earnshaw (lists) 2019-11-18 15:55 ` Segher Boessenkool 2019-11-18 16:48 ` Richard Earnshaw (lists) 2019-11-18 17:11 ` Segher Boessenkool [not found] ` <8c32c288-e9e6-b01b-7911-3f186116da85@gmail.com> 2019-11-18 17:24 ` Nicholas Krause 2019-11-18 17:26 ` Nicholas Krause 2019-11-18 17:46 ` Richard Earnshaw (lists) 2019-11-18 17:49 ` Richard Earnshaw (lists) 2019-11-18 17:55 ` Nicholas Krause 2019-11-18 18:05 ` Richard Earnshaw (lists) 2019-11-18 18:24 ` Joseph Myers 2019-11-19 11:26 ` Eric S. Raymond 2019-11-19 11:25 ` Eric S. Raymond 2019-11-19 11:46 ` Richard Earnshaw (lists) 2019-11-19 19:32 ` Eric S. Raymond 2019-11-19 19:47 ` Richard Earnshaw (lists) 2019-11-19 19:49 ` Richard Earnshaw (lists) 2019-11-19 22:14 ` Eric S. Raymond 2019-11-19 22:19 ` Richard Earnshaw (lists) 2019-11-21 16:41 ` Joseph Myers 2019-11-21 16:52 ` Richard Earnshaw (lists) 2019-11-21 18:11 ` Eric S. Raymond 2019-11-21 18:09 ` Eric S. Raymond 2019-11-21 19:22 ` Richard Earnshaw (lists) 2019-11-19 19:43 ` Richard Earnshaw (lists) 2019-11-19 22:08 ` Eric S. Raymond 2019-11-18 17:38 ` Richard Earnshaw (lists) 2019-11-18 18:53 ` Segher Boessenkool 2019-11-18 19:14 ` Richard Earnshaw (lists) 2019-11-18 19:21 ` Richard Earnshaw (lists) 2019-11-18 19:44 ` Segher Boessenkool 2019-11-18 20:53 ` Jason Merrill 2019-11-18 21:38 ` Richard Earnshaw (lists) 2019-11-19 14:57 ` Jason Merrill 2019-11-19 16:31 ` Segher Boessenkool 2019-11-19 16:47 ` Jonathan Wakely 2019-11-19 16:48 ` Jason Merrill 2019-11-19 19:36 ` Eric S. Raymond 2019-11-19 23:29 ` Segher Boessenkool 2019-11-19 23:44 ` Joseph Myers 2019-11-19 23:51 ` Nicholas Krause 2019-11-20 8:55 ` Jonathan Wakely 2019-11-20 14:50 ` Szabolcs Nagy 2019-11-20 17:30 ` Richard Earnshaw (lists) 2019-11-20 8:58 ` Jonathan Wakely 2019-11-20 11:27 ` Segher Boessenkool 2019-11-20 11:30 ` Richard Earnshaw (lists) 2019-11-20 11:42 ` Segher Boessenkool 2019-11-20 14:25 ` Jason Merrill 2019-11-20 16:01 ` Segher Boessenkool 2019-11-19 16:49 ` Richard Earnshaw (lists) 2019-12-02 10:54 ` Richard Earnshaw (lists) 2019-12-02 15:35 ` Segher Boessenkool 2019-12-02 16:19 ` Richard Earnshaw (lists) 2019-12-02 17:25 ` Segher Boessenkool 2019-12-02 17:47 ` Richard Earnshaw (lists) 2019-12-02 18:00 ` Segher Boessenkool 2019-12-02 18:11 ` Richard Earnshaw (lists) 2019-12-02 18:17 ` Eric S. Raymond 2019-12-02 20:24 ` Joseph Myers 2019-12-03 0:48 ` Segher Boessenkool 2019-12-03 9:44 ` Richard Earnshaw (lists) 2019-12-03 10:12 ` Richard Earnshaw (lists) 2019-12-02 20:22 ` Richard Sandiford 2019-12-04 23:52 ` Richard Earnshaw (lists) 2019-12-05 10:26 ` Jonathan Wakely 2019-12-05 10:32 ` Jonathan Wakely 2019-12-05 10:36 ` Richard Earnshaw (lists) 2019-12-05 10:41 ` Jonathan Wakely 2019-12-05 10:54 ` Jonathan Wakely 2019-12-05 13:18 ` Joseph Myers 2019-12-05 17:10 ` Eric S. Raymond 2019-12-05 17:22 ` Joseph Myers 2019-12-05 17:45 ` Eric S. Raymond 2019-12-05 20:14 ` Joseph Myers 2019-12-05 20:46 ` Joseph Myers 2019-12-05 21:14 ` Eric S. Raymond 2019-12-05 21:13 ` Eric S. Raymond 2019-12-05 15:33 ` Eric S. Raymond 2019-12-18 23:43 ` Joseph Myers 2019-12-19 0:01 ` Joseph Myers 2019-12-19 9:27 ` Jonathan Wakely 2019-12-19 11:05 ` Jonathan Wakely 2019-12-19 11:50 ` Richard Earnshaw (lists) 2019-12-19 11:58 ` Richard Earnshaw (lists) 2019-12-19 12:23 ` Jonathan Wakely 2019-12-19 12:33 ` Richard Earnshaw (lists) 2019-12-19 12:35 ` Jonathan Wakely 2019-12-19 12:42 ` Richard Earnshaw (lists) 2019-12-19 13:34 ` Jonathan Wakely 2019-12-19 16:00 ` Joseph Myers 2019-12-19 16:06 ` Richard Earnshaw (lists) 2019-12-19 14:29 ` Joseph Myers 2019-12-19 15:17 ` Jonathan Wakely 2019-12-19 15:20 ` Richard Earnshaw (lists) 2019-12-19 15:44 ` Jonathan Wakely 2019-12-19 15:47 ` Joseph Myers 2019-12-19 15:48 ` Jonathan Wakely 2019-12-19 15:48 ` Richard Earnshaw (lists) 2019-12-19 15:49 ` Joseph Myers 2019-12-19 16:27 ` Jonathan Wakely 2019-12-19 16:28 ` Jonathan Wakely 2019-12-19 16:33 ` Joseph Myers 2019-12-19 16:39 ` Jonathan Wakely 2019-12-19 16:43 ` Joseph Myers 2019-12-20 20:30 ` Joseph Myers 2019-12-20 21:30 ` Jonathan Wakely 2019-12-20 21:41 ` Joseph Myers 2019-12-20 22:11 ` Jonathan Wakely 2019-12-20 22:58 ` Joseph Myers 2019-12-20 23:23 ` Jonathan Wakely 2019-12-20 23:53 ` Joseph Myers 2019-12-19 11:16 ` Jakub Jelinek 2019-12-19 15:05 ` Richard Earnshaw (lists) 2019-11-04 16:19 ` Jonathan Wakely 2019-11-04 16:35 ` Richard Earnshaw (lists) 2019-11-04 17:33 ` Segher Boessenkool 2019-11-04 17:42 ` Joseph Myers 2019-11-04 17:50 ` Segher Boessenkool 2019-11-05 11:07 ` Jonathan Wakely 2019-11-05 11:28 ` Jason Merrill 2019-11-05 14:12 ` Marek Polacek 2019-11-05 21:40 ` Richard Earnshaw (lists) 2019-11-05 14:50 ` David Malcolm 2019-11-05 22:08 ` Segher Boessenkool 2019-11-05 20:16 ` Segher Boessenkool 2019-11-05 21:01 ` Iain Sandoe 2019-11-05 2:51 ` Kewen.Lin 2019-11-05 21:42 ` Richard Earnshaw (lists)
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).