This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reorganize -ffast-math code.
- To: Brad Lucier <lucier at math dot purdue dot edu>
- Subject: Re: Reorganize -ffast-math code.
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Wed, 07 Mar 2001 23:14:00 +0100
- CC: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <200103071945.OAA31638@zakon.math.purdue.edu>
Brad Lucier wrote:
> The essence of the problem is as you said. Now, this does not
> differ *one iota* from the fact that gcc on i386 spills extended
> precision registers to double precision on the stack. In doing
> so, it stores objects into slots that have less precision and
> less range than the objects themselves. This is *exactly* what
> happened with Ariane. And gcc does it in a way that (a) does
> not notify the programmer that it is being done and (b) the
> programmer cannot avoid even if he/she examines the generated
> assembley code. So, on the 386, I believe
>
> int flag_Ariane_class_disaster_math_optimizations = 1;
>
> is the default. And there should be a way to set this flag
> to zero.
Although I appreciate your comments, I think this one is mistaken,
because the problem is language dependent. As this "discussion" raged
over our mailing lists in the summer of '99, I'll just write this one
`response' - if you want to discuss this further, it's better taken off
the list ...
If I write in Fortran (which is my bread-and-butter):
REAL X, Y, Z
X = 2.71828
Y = 3.14159
Z = X + Y
the `processor' (compiler + run-time library in Fortran-speak) is free
to use whatever arithmetic is necessary to arrive at the value of Z.
The only restriction the Standard "enforces" is that it is an
"approximation" to the value of X + Y.
If the `processor' deems it expedient to use the ix86's 80-bit
intermediate values it's free to do so. It could also use 64-bit
intermediates, or 32-bit ones, or a particularly clever decimal
representation.
Remember that Fortran is derived from the actions of *human* computers.
In essence it allows what those people did (or their trade-unions
fought to be allowed). So far, so good.
Now that's a whole different kettle of fish as to the question what the
intermediate language of a multi-lingual compiler suite like GCC is
supposed to do.
I'm the first to agree (with Stephen Moshier) that the current
implementation doesn't even give the front-end implementer the
*opportunity* to use exact IEEE arithmetic.
However, that's a different problem.
--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)