This is the mail archive of the
mailing list for the GCC project.
Re: floating point war casualty list
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Stephen L Moshier <steve at moshier dot net>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 27 May 2002 21:31:35 -0700
- Subject: Re: floating point war casualty list
- References: <Pine.LNX.email@example.com>
On Mon, May 27, 2002 at 04:43:29PM -0400, Stephen L Moshier wrote:
> Here is a list of all tm.h files that defined ASM_OUTPUT_DOUBLE in
> gcc-2.95. I have tried to categorize them as still ok or not ok.
Thanks, this is helpful.
Now, to be clear, the patch under discussion is this one:
2001-12-20 Richard Henderson <firstname.lastname@example.org>
* varasm.c (assemble_real): Use REAL_VALUE_TO_x and assemble_integer
to emit floating point values.
* 1750a/1750a.c (real_value_to_target_single): New.
* 1750a/1750a.h (TARGET_FLOAT_FORMAT): New.
* 1750a/1750a-protos.h: Update.
* 1750a/1750a.h, a29k/a29k.h, alpha/alpha.h, alpha/unicosmk.h,
[...]: Remove ASM_OUTPUT_FLOAT, ASM_OUTPUT_DOUBLE,
ASM_OUTPUT_SHORT_FLOAT, ASM_OUTPUT_THREE_QUARTER_FLOAT, and
all associated support routines.
The effect of this change, as I understand it, was that if you have
double x = 3.1415926;
that gets emitted as the equivalent of
You say that
> The 10 m68k targets marked bad will fail if you try to compile
> an infinity or NaN bit pattern. The only known way to make infinity
> on them is to feed them a decimal string like 0r99e999, but since
> the barbarians that is no longer an option.
Could you please explain why emitting the bit representation of
infinity using .long will not work on these targets? Off the top of
my head, I cannot imagine any reason why, given
executing 'fmove.d fp0, x' would not leave positive infinity in fp0.
(M68k uses big-endian IEEE.)
> About 19 of the targets used the native arithmetic of the host
> computer. That is, very unfortunately, no longer an option either.
> It was our safety net. That loss of compiler configuration ability
> will make it harder to develop new ports for native targets that have
> unusual machine characteristics.
This strikes me as an exaggeration. Adapting real.c to a new form of
floating-point arithmetic, in principle, requires that one write two
conversion routines and specify whether the arithmetic possesses the
concepts of infinity and NaN. (It is currently necessary to do a bit
more, but this is an artifact of real.c being a maze of #ifdefs --
a situation that Roman and/or I will rectify in the near future.)
That is not particularly difficult compared to other hurdles in
writing a new port.
Ignoring targets that have been eliminated, you listed these targets
as potential problems due to former use of host floating point, or
The H8/300, MN10200, MN10300, and V850 have no hardware floating point
support. We use the fp-bit library for them, which simulates IEEE754;
thus the default behavior of real.c is correct. If
REAL_VALUE_TO_TARGET_* did not work for IEEE we would have heard about
it by now.
The SH has hardware IEEE floating point support. The romp used
various different coprocessors, but they all implemented IEEE754.
Again, we would have heard about it by now if there were problems
with real.c emulating IEEE.
That leaves the i370 (IBM_FLOAT_FORMAT), pdp11 (VAX_FLOAT_FORMAT, or
should be), and ns32k (no idea) as potential problems. Can people
familiar with these targets say what the situation is?
p.s. Of the list you provided, these targets have been eliminated in
The romp, m88k, and ns32k are currently slated to be dropped in 3.3.