Re: GCC build failed with your patch on 2001-01-09T11:35:00Z.

[Mark Mitchell <mark at codesourcery dot com>]

>>>>> "David" == David Edelsohn <dje@watson.ibm.com> writes:

    David> 	Oh, cool!  I get to be embarrassed too as I explain
    David> this incorrectly!

Thanks for trying.  That cleared up some of my questions.

I think the short-term answer is that we should back out this patch
until after we branch for GCC 3.0, and simultaneously continue the
debate.

I think the first question to answer is, as you say:

  First order, determine if imposing 64-bit H_W_I for 64-bit targets
  really is correct.

It sounds like that will improve the generated code in most cases (due
to the fact that we can do more optimizations on a CONST_INT), but
possibly impact compile-time performance.  It sounds like it will also
make it more likely that you get the same output from a cross-compiler
as from a native compiler (since you get the same size H_W_I in the
cross environment as on the host).  So, on balance, this seems like a
good thing.

Another alternative, that I've played with mentally, is to make the
host actually fully able to emulate the target arithmetic.  Rather
than this stuff with (in trees, for example) TREE_INT_CST_LOW and
TREE_INT_CST_HIGH, just have a wide-integer type that has the full
precision of the target.  If possible, use native arithmetic; if not
possible, use simulated arithmetic.  I have always found the
hard-wiredness of exactly two fields, and such, to be inflexible,
brittle, and unappealing.

If we worked towards that goal, instead of taking Alexandre's
approach, then I think lots of things would get better, at the
possible expense of compile-time performance.

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