Re: Small update to reversed_comparison_code

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

    Your basic point is that the (say) SPARC maintainer should be
    responsible for tracking down problems on the SPARC, even for problems
    that didn't originate from that persion.

SPARC's a bad example because it's a well-known and common architecture.

My concern is if a useful patch breaks, say, the C4X port due to a latent
bug in the back-end, it's not necessarily reasonable for the person who
submitted that patch to work on it.  Not everybody is familiar with all
parts of the compiler and if a proper patch breaks something in an
unfamiliar area, it's not always practical for them to fix it.

    There may be situations where everyone agrees that (say) the SPARC
    back-end is broken, and that it is better to break the SPARC bootstrap
    for a while in favor of some patch that does something good.

That's basically what I'm saying.

    There are very few problems that cannot be fixed using a
    cross-compiler.  Anyone who is checking things in to
    platform-independent parts of the compiler should be prepared to use a
    cross-compiler to track down problems with their changes.

It's impossible to fix a bootstrap problem using a cross-compiler unless
somebody who has the target machine has identified what was miscompiled,
for example.  But it's not just lack of a physical machine, but the issue
of whether the submitted can be expected to have familiarity with some of the
more obscure ports.

    For bootstrap failure, there is no small breakage.  If you do `make
    bootstrap' and you get an error, you cannot do your work.

Yes, but the machine that's broken matters.  It's much more serious if
we break a bootstrap on, say, ia32 or SPARC than on VAX.