This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Beyond GCC 3.0: Summing Up
- To: dewar at gnat dot com
- Subject: Re: Beyond GCC 3.0: Summing Up
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 10 Jul 2001 01:24:05 -0300
- Cc: kenner at vlsi1 dot ultra dot nyu dot edu, mark at codesourcery dot com, gcc at gcc dot gnu dot org
- Organization: GCC Team, Red Hat
- References: <20010710031120.960A5F2B12@nile.gnat.com>
On Jul 10, 2001, dewar@gnat.com wrote:
> If your patch causes things to fail that did not fail before, then
> your patch is ultimately at fault!
Even when the patch also causes things to work that did not work
before? Is it more important to keep the set of known failures
unchanged than to make progress by fixing a bug, even if exposing
another latent bug? I don't think so.
As an extreme example, how about patches that introduce new testcases,
that happen to not work on certain platforms? Should they be
immediately reverted, on the grounds that the failure was not (known
to be) there before?
How about a patch that fixes a problem in some port, and comes with a
testcase that happens to exercise the same bug in another port? Does
the patch have to be reverted just because the bug-fixer didn't even
know about that other target?
Exposing latent bugs is a good thing, and the more eyes we can get to
look at the failure, the better. I believe leaving the breakage in
the default CVS tree will get more eyes looking into the problem, so
that it gets fixed faster. Reverting the patch so as to return to the
previous broken state is just papering over the problem. If we reject
patches that paper over problems, which we do, why should we encourage
patches that revert patches that exposed latent bugs?
I agree we should have means for those who can't afford to spend time
investigating a newly-exposed failure to easily get the compiler back
to the original set of known failures (which is why I propose that we
keep such patches in Gnats), but I don't agree that reverting a patch
that fixes a bug but happens to expose another latent bug is a good
thing for GCC in the long run.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me