Re: Beyond GCC 3.0: Summing Up

[Bernd Schmidt <bernds at redhat dot com>]

On Tue, 10 Jul 2001 dewar@gnat.com wrote:

> Second, sure new code may have bugs, but it is not at all the case that
> new code will always cause breaks in the existing test suite. Many bugs
> are in fact target independent, and will show up if anyone executes the
> test suite.

The test suite is far from covering all of gcc.  I read Mark's message as
if he wanted to make sure that for any given program, if gcc version X
compiles it correctly, then gcc version X+1 will do so as well.  (Not sure
if performance criteria apply as well).  The testsuite won't help at all
with such a goal.

> I did not have the impression that the reversion would be anything like
> that automatic, and I would definitely not support any automatic process.
> I have not seen anyone suggest anything like this.
>
> Yes, of course, if a patch breaks things, we try to find out what is
> going on.

I'm concerned because I've seen cases where that has not happened, or
where reverting a patch has been suggested without determining why it
caused a failure (even in a case where everyone agreed it was obvious
the patch couldn't possibly be the cause of the observed problem).
This is what I want to prevent.

> That's the question, and Mark and I feel that in this situation, if we
> cannot get a quick resolution, then we have to revert the original patch,
> so that the status quo of the test suite passing on all targets is
> reachieved.

I'd prefer to delay such an action until a release is imminent, on the
grounds that a failing test is a useful piece of information we shouldn't
lose (of course this requires that we keep track of why it's failing).  A
bug that doesn't show up in the testsuite tends to get ignored even more
than a known regression.


Bernd