Re: Reorganize -ffast-math code.

[Brad Lucier <lucier at math dot purdue dot edu>]

> Read that footnote again. In particular
> 
>   "An implementation should not provide operations that combine double or
>    extended operands to produce a single result, nor operations that
>    combine double extended operands to produce a double result, with only
>    one rounding."
> 
> the above is _exactly_ what gcc does.

(1) This is a "should", not a "shall"; so even if some implementation
did this, it would not violate the standard.  (2) The IEEE standard deals
with single operations, not groups of operations; x86 hardware doesn't have
single operations to do this, and the standard doesn't address what gcc
does to groups of operations.  The text body is very careful
to separate range and precision; in the main text I quoted, it says it's
OK to take two extended format operands and produce a result with a smaller
precision than extended precision in a single operation with only one
rounding, but here it says one should not to produce a "double result",
which means with both the precision and range of a double, "with only one
rounding".

> Gcc will normally keep values in
> registers as long as it can, because doing anything else is horribly bad
> for performance.

This is obvious.

> And by doing that, gcc is _not_ IEEE conformant,

The IEEE standard does not address combinations of more than one operation,
so whatever gcc does in this regard does not violate the IEEE standard.

> exactly
> because it will combine extended operands with one one rounding.

I don't know why you say this, it doesn't happen.

> So I stand by my claim that it violates IEEE. But people _know_ this, and
> it has been deemed acceptable behaviour.

I don't care for appeals to authority.

> That's what -ffloat-store helps with. Then you'll get rounding in between
> rounds, not just the one final rounding.

The IEEE standard and you are using the phrase "one rounding" differently.
For example, the IEEE standard considers the initial rounding of the
infinite precision result of the sum x+y (where x and y are doubles) to
extended precision on the x86 to be a "rounding".  So if you leave
the x87 precision at extended and use -ffloat-store, you will get double
rounding, once when x+y is rounded to extended, and once again when
the extended intermediate result is stored into a double destination.
If you specify "round operations to double precision" on x86 hardware, then
x+y will be rounded to 53 bits precision.  Then if you do -ffloat-store,
the result will be rounded again only if the result is a double
format denormal (which the scaling in my previous e-mail eliminated),
and the operand will be forced into a double format range.
-ffloat-store doesn't help you with rounding (which pertains to
precision) but with range.




The problem is that code compiled with gcc does not have predictability and
reproducibility of results on the x86.  I'm not talking about comparing the
result on an x86 with the result you get on an Alpha, I'm talking about
the same expression on x86 giving you different results depending on where it
appears in the code.  As you say, for most applications (and for the
purposes of the Fortran 77 standard) this doesn't matter.  But for some
it does, and gcc is useless for building those applications.

Brad