Re: Small update to reversed_comparison_code

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "Richard" == Richard Kenner <kenner@vlsi1.ultra.nyu.edu> writes:

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

There are examples where the process I outlined works effectively.

For example, the Mozilla "tinderbox" works in essentially this way.
Multiple, cross-platform builds are done and build failures are dealt
with quickly.

Everything is a question of degree.  If the bootstrap was broken every
now and then and fixed momentarily, then there would be no issue.
When, however, it is broken on major platforms for weeks on end, that
is another thing.

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.

I think that's a mistake.  There should be a shared responsibility.
People who check in things should be willing to fix problems that
occur as a result of those changes.  People who care about SPARC
should pitch in and help.  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.

However, that should not be the norm.  Every time the tree fails to
bootstrap, people lose tons of work.  Frankly, I would estimate that
Jeffrey has lost over 100 hours in the last *three months* tracking
down bootstrap problems introduced by other people on IRIX and
GNU/Linux.  That is completely unreasonable.

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.

    Richard> are.  The smaller the breakage, the more tolerable it is

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

    Richard> My concern is *documentation*.  If something is broken,

I agree -- but that's orthogonal.

    Richard> there's a lot of "peer pressure" to get it fixed, but if

In practice, this must be false.  For example, the x86 bootstrap has
been broken for over a week, and the responsible parties were
notified.  They didn't fix the problem.

That's why I supported Jeffrey's request to back out the patches.

There are *lots* of latent bugs in GCC.  Exposing them is good; fixing
them is better.  But, exposing them and not fixing them does not
actually allow anyone to make progress.

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