On 4/16/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap
Honza, PING!
31360 [4.2/4.3 Regression] rtl loop invariant is broken
Zdenek, PING!
The broader question of why there are so many 124 P3 or higher regressions against 4.2.0 points to a more fundamental problem.
Quick bug breakdown: 46 c++ bugs: 13 of these are assigned 33 missed-optimizations: 7 of these are assigned So that's 79 of 124 bugs, almost two thirds of all bugs. Only 6 of the 124 bugs are reported against a compiler older than gcc 4.0, so most of these regressions are fairly recent. Only 29 of 124 bugs are assigned to a developer, but some bugs have been assigned since forever to the assignee without any sign progress towards a fix, ever. So in reality, even fewer than 29 bugs have an active assignee. That's less than one fourth of all "serious regressions" being taken seriously. Then again, all things considering it seems to me that having 33 missed optimizations as regressions only makes things look terribly bad, while in reality the situation is really not so bad at all. The usual discussion about bikeshed regressions vs. real significant progress: With 33 missed optimizations, GCC 4.2 still produces measurably better scores on the usual benchmarks. So maybe the fundamental problem is that we just have bugs that look more serious than they really are. Certainly some of the missed optimizations are pretty severe, but the majority of these reports is just silly.
Despite the fact that virtually all of the bugs open against 4.2.0 are also open against 4.1 or 4.3 -- or both! -- there seems to be little interest in fixing them.
Interest in fixing regression typically peaks in the days after the Release Manager posts a bug overview / release status. We haven't had very many updates for this release... ;-)
Some have suggested that I try to solve this by closing GCC 4.3 development until 4.2.0 is done. I've considered that, but I don't think it's a good idea. In practice, this whole software freedom thing means that people can go off and do things on their own anyhow; people who are more motivated to add features than fix bugs are likely just to keep doing that, and wait for mainline to reopen.
I think that, as the Release Manager, you should just near-spam the list to death with weekly updates, and keep pushing people to fix bugs. I think most of the time, people don't fix their bugs simply because they're too involved with the fun stuff to even think about fixing bugs. That's how it works for me, at least. I think the release manager should try to get people to do the hard work of identifying the cause of bugs, which is usually not really hard at all. For example: * Janis has more than once been asked to reghunt a regression, and she's always been very helpful and quick to respond, in my experience. * Very few people know how to use Janis' scripts, so to encourage people to use them, the release manager could write a wiki page with a HOWTO for these scripts (or ask someone to do it). Regression hunting should only be easier now, with SVN's atomic commits. But the easier and more accessible you make it for people to use the available tools, the harder it gets for people to justify ignoring their bugs to "the rest of us". * Maintainers of certain areas of the compiler may not be sufficiently aware of some bug in their part of the compiler. For example, only one of the three preprocessor bugs is assigned to a preprocessor maintainer, even though in all three preprocessor bugs a maintainer is in the CC. It's just that the bugs have been inactive for some time. (And in this particular case of preprocessor bugs, it's not even been established whether PR30805 is a bug at all, but it is marked as a P2 "regression" anyway) In summary, I just strongly encourage a more active release manager... As of course you understand, this is intended as constructive criticism. Gr. Steven
