Re: Reorganize -ffast-math code.

[Toon Moene <toon at moene dot indiv dot nluug dot nl>]

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)