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

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Mark Mitchell writes:

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

	Handling the full range of target data types is necessary.  I
think that 64-bit HOST_WIDE_INT is just a band-aid.  IBM's XL compiler,
and I presume most other commercial compilers, implement the manipulation
of constants themselves with minimal assumptions about the host data type
model.

	Relying on the host's and host compiler's data types is the root
of this problem.  Fixing it in GCC is a huge undertaking because the
flawed assumption is so fundamental to GCC's design.  GCC should call its
own routines to compare values, not relying on the underlying data types
of the host.

	I agree that TREE_INT_CST_{LOW,HIGH} and CONST_DOUBLE_{LOW,HIGH}
fixed, two-field implementations, as well as CONST_INT are the problems
that we really are trying to address.  The questions: are there
incremental improvements that can evolve towards correctness, as opposed
to a wholesale re-write?  And, what are the best short-term solutions /
kludges / work-arounds?

David