Re: Beyond GCC 3.0: Summing Up

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    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".

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.

    Well, maybe a change that exposes a latent bug can go in on a branch
    or something, to make it easier for others to work on it.  After the
    bug is fixed the branch can be removed.  

Perhaps, but I get very concerned about the number of branches and the work
in merging them all back in if this is a common practice.

    But I think this should only be done after we have pretty good
    agreement among the experts involved that this is a true latent bug,
    and not just a disagreement about assumptions.

Right.  A good example was what happened to me a few days ago. There
was a call to adj_offsettable_operand in caller-save.c which was
clearly bogus: that function is supposed to only be called on an operand
for which offsettable_memref_p is true and passed an offset smaller than the
size of the operand and neither was true in that case. 

So my change in that area clearly exposed a latent bug.  Since I also know
that part of the compiler quite well, it took a total of five minutes
plus compilation time to fix, but I'm concerned about people who don't
know that compiler that well.