This is a meta-bug for old(!) compile-time and memory-usage regressions that we keep not closing for whatever reason and that are present on all active branches. Those bugs got their regression markers removed now and instead are liked from this single regression bug.
Confirmed.
4.3 branch is being closed, moving to 4.4.7 target.
*** Bug 34983 has been marked as a duplicate of this bug. ***
class a{int i;}ai;
4.4 branch is being closed, moving to 4.5.4 target.
The 4.5 branch is being closed, adjusting target milestone.
This bug looks like the wrong idea to me. Old is apparently anything older than the maintained release branches, but many users "in the field" still use older compilers that come with their respective distributions. For instance a regresion that is present since GCC 4.6 but not in GCC 4.5 gets reduced in importance and visibility by not marking it as regression and instead only adding it to this grab-a-bag PR. Example of such a case is bug 53958. This is a change of old existing policy that any regression should be marked as such. This policy change should have been discussed (and IMHO rejected) on the GCC mailing list. Also, this meta-bug depends on not-so-old regressions, so it's already more like a collection of compile/memory hog issues than a collection point for apparently "unimportant" regressions.
On Wed, 6 Mar 2013, steven at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47344 > > --- Comment #7 from Steven Bosscher <steven at gcc dot gnu.org> 2013-03-06 10:51:27 UTC --- > This bug looks like the wrong idea to me. Old is apparently anything > older than the maintained release branches, but many users "in the field" > still use older compilers that come with their respective distributions. > > For instance a regresion that is present since GCC 4.6 but not in GCC 4.5 > gets reduced in importance and visibility by not marking it as regression > and instead only adding it to this grab-a-bag PR. Example of such a case > is bug 53958. > > This is a change of old existing policy that any regression should be > marked as such. This policy change should have been discussed (and IMHO > rejected) on the GCC mailing list. > > Also, this meta-bug depends on not-so-old regressions, so it's already > more like a collection of compile/memory hog issues than a collection > point for apparently "unimportant" regressions. All these regressions clutter the list of important regressions. All of them are present in more or less severe form in all maintained branches. There is a similar issue for missed-optimization regressions that are long-standing.
(In reply to comment #8) > All these regressions clutter the list of important regressions. And why would all of these not be important? Hiding a problem is not solving the problem. And it always was policy that a regression should be marked as such. If it is not important enough, you can set its priority to P4 or P5, but we should never remove the regression marker. See http://gcc.gnu.org/ml/gcc/2007-12/msg00550.html
I agree with Richard here, it isn't that much hidden, simplifies RM tasks and allows us to actually release the compiler in roughly timely manner.
(In reply to comment #9) > (In reply to comment #8) > > All these regressions clutter the list of important regressions. > > And why would all of these not be important? > Hiding a problem is not solving the problem. > > And it always was policy that a regression should be marked as such. If > it is not important enough, you can set its priority to P4 or P5, but we > should never remove the regression marker. > > See http://gcc.gnu.org/ml/gcc/2007-12/msg00550.html Well, the issue with these kind of testcases / bugs is that we cannot easily mark them as dups of each other because nobody separates the issues the testcases show into separate bugreports (which could be individually marked as regression). So the bugs tend to stay open forever, with much confusion as to what issue (still) exists or has popped up again or new. Tracking the testcases so we see when they regress again is important (and gcc.opensuse.org/c++bench/random is just a lame attempt, because C++ issues keep breaking testcases and because the machine has not enough memory to keep up with the task - and the scripting is lame, too ;)) I realize this meta-bug is a bad attempt at making the important regression numbers look better ;)
GCC 4.6.4 has been released and the branch has been closed.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed
GCC 5 branch is being closed
GCC 6 branch is being closed
The GCC 7 branch is being closed, re-targeting to GCC 8.4.
GCC 8.4.0 has been released, adjusting target milestone.
GCC 8 branch is being closed.
GCC 9.4 is being released, retargeting bugs to GCC 9.5.
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
GCC 10 branch is being closed.