Re: Beyond GCC 3.0: Summing Up

[Mark Mitchell <mark at codesourcery dot com>]

>
> A real-life example: the reload patch I did just before 3.0 which deleted
> all USEs generated during reload.

Actually, I think this example is a good one for showing why the
reversion policy is good.  I very much appreciated your attempt at
a patch, but going down a road of cascading changes (we change the
MIPS backend, but then break something else, then go change that)
at the point we were in the release would have been a wrong decision.

There is no question that the reversion policy raises the bar for
patches, and puts burdens on patchers that should perhaps, in a
more equitable world, be born by the original coders.  The long-term
solution to that problem is better documentation of how sections of
the code have to work, and better tests for conformance.  (Unit testing,
for example, of particular pieces of things.)

But, it's time that as contributors we all recognize that in order to make 
the compiler better, one of the things we have to do is to start shaking 
the bugs out.  One way to do that is to make the people checking in new
code fix bugs in the old code, and this a mechanism towards that end.

GCC needs to generate better code and support more platforms.  But,
perhaps even more importantly, it needs to be correct on the platforms
that it supports, it needs to not fall over on erroneous input, and
each release needs to be *monotonically* better than the one before.

But, your opinion is on the record, and so is mine.  Rather than debate,
I'd prefer to let the SC make up its collective mind.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com