GCC 4.2.0 status report

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
mark@codesourcery.com
(650) 331-3385 x713