Re: Beyond GCC 3.0: Summing Up

[Joe Buck <jbuck at synopsys dot COM>]

>     An alternative is that the person can write to the gcc list, describe the
>     latent bug in reload that is found, and ask for help with it.  Maybe a
>     volunteer can be found to fix the latent bug, and then the improved
>     combine.c can go in.  But breaking the compiler isn't an option, as it
>     stops all work.  
> 
> "breaking" isn't binary.  Clearly, if a patch makes the compiler not
> bootstrap on a major target, we have a problem that needs urgent fixing.
> But the standard for patch correctness is much stricter: if a patch breaks
> a handful of test cases on one or two targets, it's hardly the case that
> it "stops all work", but we do consider that "broken".

OK, I agree with you that such a standard is too severe.  We can't break
bootstrapping, but if the latent bug just causes a few testcases to fail,
then the best thing to do would be to leave it in, unless we're about to
release.  If we're about to release, the changes might have to wait.
Maybe such things get worked out case-by-case, though I'm still worried
about gradual erosion (lots of changes cause a few new regressions here
and there and everyone blames "latent bugs").

> That's why I think it's important to look at the extent of the breakage
> and use that as a criteria in what to do about the breakage.