Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[dewar at gnat dot com]

<<No, you should have written (a*c) + (b*c) if you wanted the first
expression *instead* of the second one - heck, you say so yourself, in
the above (... full of parentheses ...)
>>

I really don't understand the "No" here. Please reread my message. Yes
of course, to fully follow the standard you put in the parens, as I noted
earlier, Fortran code tends to be full of parens for this reason.

But ... my point was that *EVEN IF* no parens were present, I would be shocked
to find the Fortran compiler using the associative law to rewrite my 
expression.

After all, if you really believe that a Fortran compiler is not only allowed
(true) but reasonably may (false) perform any kind of such "optimization",
there are some pretty weird results that can occur in the extreme.

Actually most Fortran programmers, even those not doing careful error
analysis, tend to be quite disturbed if optimization changes results,
even if this is allowed by the standard.

If you write

  A = B * C

  IF (A.EQ.B*C) ...

it is a surprise for the IF to yield False, even though the standard permits
it. Kahane in fact declares this to be a bug, and cannot be mollified by
being told that the standard permits this "bug".

I know that IBM in their Fortran compiler for the Power architecture (and
remember IBM is targetting knowledgable numeric programmers there) decided
that in optimization mode they should still round to single precision when
calculations are done in registers, and avoid the phenomenon of getting
unexpected extra accuracy for register calculations [the reason incidentally
behind the misbehavior of the IF above].

The x86 of course is quite a nightmare from this point of view (at least
the traditional 80-bit stack based arithmetic is a nightmare, the newer
fpt on the later Pentiums and Athlons is better).