On 6/18/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
Giovanni Bajo wrote:
> Both our goals are legitimate. But that's not the point. The point is
> what -ffast-math semantically means (the simplistic list of suboptions
> activated by it is of couse unsufficiente because it doesn't explain how
> to behave in face of new options, like -mrecip). My proposal is:
>
> "-ffast-math activates all the mathematical-related optimizations that
> improves code speed while destroying floating point accuracy."
I don't think that's a workable proposal. If it is taken literally, it
means that the optimization of converting all floating-point arithmetic
to no-ops and replacing all references to floating-point variables with
zeros is allowed (and would be appropriate under this option).
And, personally, I don't think that documentation is of use if it can't
be taken reasonably literally. There's a line between what's acceptable
and what's not, and regardless of where exactly it is, the documentation
needs to fairly clearly indicate its location.
I agree. 'destroying floating point accuracy' is too broad and
discuraging. Even if in some cases this is exactly what happens - the
error we introduce (if you define it as difference of result with and without
-ffast-math) is essentially unbound. Still in most 'regular' cases we
preserve accuracy quite well or even improve it (for some other metric
of accuracy).
This is really a hard to solve communication problem.
OTOH, if we start to produce NaN for sqrt(0.0) that is of course simply
'wrong', not inaccurate ;)
Richard.
