As has been remarked on the GCC mailing lists, I've not succeeded in getting GCC 4.2.0 out the door. However, with the limited criteria that we target only P1 regressions not present in 4.1.x, we seem to be getting a bit closer. The only regressions in this category are:
26792 [4.2 Regression] need to use autoconf when using newly-ad... 29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap 30222 [4.2 Regression] gcc.target/i386/vectorize1.c ICEs 30700 [4.2 Regression] YA bogus undefined reference error to st... 31136 [4.2 Regression] FRE ignores bit-field truncation (C and ... 31360 [4.2/4.3 Regression] rtl loop invariant is broken 31513 [4.2/4.3 Regression] Miscompilation of Function Passing B... I'm disappointed that the patch for PR 30700 hasn't been applied to the 4.2 branch; according to bugzilla it looks like all that's needed is a build/test cycle there. I'll be tackling 31513 tonight. Perhaps I can get to one or two of the other PRs above. The broader question of why there are so many 124 P3 or higher regressions against 4.2.0 points to a more fundamental problem. 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. 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. However, I would consider asking the SC for permission to institute a rule that would prevent contributors responsible for P1 bugs (in the only possible bright-line sense: that the bug appeared as a result of their patch) from checking in changes on mainline until the P1 bug was resolved. This would provide an individual incentive for each of us to clean up our own mess. I'm certain that someone will raise the "latent bug" issue, but that's not the common case. And, we can always decide to make an exception if necessary. Of course, if we do this, I'd be happy to recuse myself as necessary, in order to avoid any appearance of favoritism towards CodeSourcery personnel. What do people think of that suggestion? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
