Re: Small update to reversed_comparison_code

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

    In this particular case, Richard is doubly not to blame because the
    problem only occurs with --disable-checking, which was not the default
    configuration on the branch when Richard checked in his patch.  So,
    I'm certainly not blaming Richard!

I'm certainly not blaming him either (and to avoid ambiguity, we are
talking about Richard Henderson here).

    However, you are essentially arguing that if a patch tickles a latent
    bug, then it should go in anyway -- to incentivize people to fix the
    bug.  That discounts the cost to the organization as a whole of not
    being able to build anything.

I wouldn't consider a miscompare during a bootstrap as "not being able
to build anything".

    The right solution is to hold on to the patch, and figure out the
    latent bug.  The person contributing the patch can do that, or they
    can explain the problem to someone else so that the someone else can
    fix the problem.  The person who wants the original patch checked in
    is incentivized to get the latent bug fixed.

Yes, but is that enough?  Look how many people have contributed to
tracking down this problem in recent days?  Would that ever have
happened if the patch had immediately been removed?  Who would bother?

The other issue is that the overall reliability of GCC is increased if
these latent bugs are brought out and fixed.  If some minor change
triggers a latent bug and the developer who made that change isn't
versed in the area of the compiler in which the latent bug has
appeared, they may just decide the change isn't worth it.  That means
the latent bug may never get fixed.  I'd argue that it's better to
take some short-term penalty in cases like this and ensure the bug
gets fixed than to "blame" the unrelated change and sweep the latent
bug back under the rug.

    More concretely, if we cannot agree on policies that keep the tree
    working on major platforms most of the time, 

I certainly agree that the tree should work on major platforms most of the
time.  My argument is that trying to attain a standard where it works on
most (not just major) platforms *all* of the time will have the effect of
hindering development and keeping latent bugs hidden.

    No organization, commercial or otherwise, wants to commit resources to
    fixing other people's bugs as often as has been necessary recently.

But most of the recent failures have been in "third party" bugs: where
the bug was neither in the change that was made nor in the
organization's sphere, but instead somewhere else (in some cases in
still unknown places).  I think that everybody has to share the cost
in finding those.

I agree that the case of an outright bug in somebody's change is a different
situation, but that's not been the most common problem.