Re: Beyond GCC 3.0: Summing Up

[Mark Mitchell <mark at codesourcery dot com>]

--On Tuesday, July 10, 2001 01:24:05 AM -0300 Alexandre Oliva 
<aoliva@redhat.com> wrote:

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

I do, but perhaps I am radical.

How would you feel if a new version of the kernel broke a syscall
or two, but made process invocation faster?  Or if the new version of
X displayed bitmaps faster, but occasionally locked up when running
GNOME?  Or if a new web-browser had support for animated GIFs, but
all JavaScript pages that used to work stopped working?

When that kind of thing happens, it is very frustruating.  As a user,
I've sometimes had two of something -- and used one version for some
things and the other for other things.  That drives me crazy in a
hurry.

What I want to do is make sure that people that download the next
version of GCC can just use it to do what they did before -- and
more!

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

No.  If the failure is not new (only our knowledge of it), then the
test-case should be XFAILed for that platform, and a PR filed, and
that's that.

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

No.  The test-case should be XFAILed and a PR filed.

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

This argument is common -- but seems to be refuted by the fact that
literally hundreds of regressions were fixed on the 3.0 branch, and
that many more remain.  Why weren't they fixed earlier?  Many of them
were reported months and months before they were fixed.

> Reverting the patch so as to return to the
> previous broken state is just papering over the problem.  If we reject

But there was no problem for the user.  If we had code that
behaved essentially randomly, and we just changed the set of input
cases where the bad behavior appeared, and there were roughly as many
as before, I *might* see things differently.

But, if we had code that was "wrong" in the sense that it didn't
conform to our sense of how the compiler should be written, but never
resulted in a bug for users, and now it does, then the latent-bugness
is just irrelevant.  The compiler used to work, and now it doesn't;
ergo, we broke it.

> patches that paper over problems, which we do, why should we encourage
> patches that revert patches that exposed latent bugs?

We'd be encouraging the poster to take responsibility for fixing the
latent bug as well.  The poster would want to get her patch checked
in, so she would either fix the latent bug, or lean on other people
to fix it.  It's just an ordering thing: if we can't get anyone to
fix the latent bug before checking in the patch, or as soon as the
problem is noticed, why do we think we can get someone to fix it
afterwards?

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

That shifts the burden to people who had nothing to do with the patch;
people who were neither the original poster, nor the author of the
latent bug, not the person who is supposed to maintain that part of
the compiler.  And, *all* such people must do the work of reverting
the patches locally to make progress.

Since, under my proposal, reversion only occurs if nobody is working on a 
fix in the short term, we are, by hypothesis, going to be saddled with the 
breakage for a longish period of time.  Why not simply revert the patch, 
and/or put it on a branch, so that people can work on fixing the latent bug 
without interfering with everyone else?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com