Re: Beyond GCC 3.0: Summing Up

[Joe Buck <jbuck at synopsys dot COM>]

Kenner writes:

> I share these concerns, but would also specifically add that a major problem
> with the proposed scheme is that it greatly increases the amount of knowlege
> a person needs to have to modify GCC.  If somebody spends a lot of time
> learning, say, combine.c and makes a correct change to it but that change
> triggers a latent bug in reload.  Is it reasonable for that person to have to
> understand reload (perhaps the most complex part of the compiler) in order to
> finish their work?  Aside from whether it's reasonable or not, is it actually
> going to *happen*?

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.  People who have other projects can't get work done.
You free up the first contributor from having to know reload, but as soon
as the world breaks, only those who know reload can un-break it.

> I don't have a good solution to the problem, but I am concerned that if we
> don't treat latent bugs differently we are going to both drive away new
> contributors and not have the high-quality that would be obtained by making
> sure the latent bugs get fixed when they are discovered rather than buried.

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