On 4/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
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.
This is certainly what I would do. I fixed all the critical 4.2 bugs
I was responsible for. I have no plans to fix the non-critical ones
because to be honest, 4.2 lacks a lot of the infrastructure to fix
them in sane ways.
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.
And how exactly would we plan on tracking this?
At least to me, it seems like adding more administrative overhead and
i don't see it fixing the underlying problem.
You want more bugs fixed, it would seem a better way would be to build
a better sense of community (Have bugfix-only days, etc) and encourage
it through good behavior, not through negative reinforcement. You
can't fix behavior in a volunteer community by beating people into
submission. There will always be those who don't get it, or who
everyone believes isn't doing a good job, and it's not just because
they are committing patches and leaving messes. The reality is we
just don't want people like this in our community, and they shouldn't
have write access, TBQH[1].
This is not to say we shouldn't accept/review their patches and commit
them for them. But with write access comes a level of trust.
--Dan
[1] Then again, I think our system of granting more than
write-after-approval access based on the secret discussions of a bunch
of people, some of whom don't even work on gcc anymore, is flawed
anyway, so take it for what it's worth . It's really not a dig
against the SC as people, most are great people. As an entity, I
don't believe this should be in it's job description. I firmly
believe the decision of who gets write access should be in the hands
of the committers, since those are whom are most affected, and those
who are continually active.
