Re: Small update to reversed_comparison_code

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

    I'm not going to comment on the other (technical) parts of your
    message.  I am too busy trying to work on other projects.  However, in
    general, I would say that if there is something fundamentally wrong
    with a particular feature, then (as you suggest), we must disable it
    on the release branch.  Correctness first.

For the release branch, I agree, however:

    In fact, one of our SC members has suggested automatically removing
    patches that fail Geoff's regression checker, and others have gone so
    far as to suggest requiring an automated cross-platform bootstrap
    *before* check-in.

I have major concerns about this.  GCC has a lot of targets and a
large number of language front-ends.  It's infeasable for any
developer to test on more than a tiny fraction of such configurations
or even to have *access* to more than a small fraction of such.

Witness the recent query about whether somebody (I forgot who) had
access to a MIPS configuration to fix something broken on that
configuration.  Another example was the enabling of the validity check
on blocks which exposed what looks like a latent problem in the Java
front end.

I think it's unreasonable to expect a developer who produces a useful
and basically sound patch to be able to deal with a failure of that
patch on any possible configuration.  It needs to be the
responsibility of the maintainer of a configuration (or, more
generality, anybody who has access to that configuration) to assist in
fixing the problem on that machine (or language).

This is especially true because many patches are completely correct,
but expose latent problems elsewhere, usually in back-ends.  The
person contributing the patch is often quite unlikely to be able to
fix this sort of latent problem.  So any sort of automated procedure
would make it very difficult for such patches to make it in and also
to expose and fix such latent bugs.

    It is unacceptable to check in changes which break bootstraps.  If
    the problem cannot be fixed easily, then the change needs to be
    removed.

I think this is a function of the extent of the breakage: how many
machines and languages and how "important" they are.  The smaller the
breakage, the more tolerable it is to keep things broken for a while
to give things a chance to be fixed.  It's far easier to
colaboratively work on a fix when the patch is still installed than
when it's been removed.

My concern is *documentation*.  If something is broken, there's a lot
of "peer pressure" to get it fixed, but if something "merely" isn't
well documented, there's no such pressure.  So, in my opinion, it's
much worse to allow a change in if it's incompletely documented than
it is if it causes a problem in some obscure configuration.