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

[Gabriel Dos Reis <gdr at codesourcery dot com>]

dewar@gnat.com writes:

| <<What I intended to mean is that the compiler has, first, to prove that
| such transformmation yields the same result.  The only argument I've
| seen so far is that, GCC should make the program run fast...
| >>
| 
| Not quite, "the same result" is too strong. Instead, the rule is that
| the transformation must yield a result that is still conforming to the
| requirements of the standard. Since the standard is (deliberately) not
| 100% precise in saying what this result should be, there is some legitimate
| wiggle room.

Transforming a/b/c into a/(b*c) where (b*c) overflows whereas (a/b)/c
does not isn't something acceptable (speaking here as a user or a
numerical programmer).  Even if C++98 is as vague as C90 was about
floating point arithmetic, the move is that the next revision of the
Standard will provide a sound framework and support for numerical
computations; I don't think speed is enough to justify incorrectness.
I don't think that the impreciseness in C++98 makes it OK to apply
dubious rules.

That doesn't mean I don't want optimization.  I do love optimization.
By optimization, I really mean optimization.

That said, I don't mind about -fdubious-math as far as it is not the
default, nor turned on at any level of optimization.

-- Gaby