Re: Reorganize -ffast-math code.

[Linus Torvalds <torvalds at transmeta dot com>]

On Wed, 7 Mar 2001, Brad Lucier wrote:
> 
> The IEEE 754 Standard says the following:

You seem to be quoting the standard without actually _reading_ it.

> Footnote [4]: Control of rounding precision is intended to allow
> systems whose destinations are always double or extended to mimic,
> in the absence of over/underflow, the precisions of systems with
> single and double destinations.  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.

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. Gcc will normally keep values in
registers as long as it can, because doing anything else is horribly bad
for performance. And by doing that, gcc is _not_ IEEE conformant, exactly
because it will combine extended operands with one one rounding.

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

That's what -ffloat-store helps with. Then you'll get rounding in between
rounds, not just the one final rounding. But it's bad for performance, and
most people don't care - very few FP applications need to have rounding of
even the intermediate results to work correctly.

So I don't understand your arguments. You're claiming that gcc silently
truncates FP values to less than the programmer-asked-for-precision, even
though the problem is the _reverse_. And when I point out your error, you
argue by quoting a standard that just reinforces my point. It's a strange
way of arguing, and not very effective.

Maybe I've misunderstood the whole problem. I'll go away now.

		Linus