Paul Koning <[EMAIL PROTECTED]> writes: > After some off-line exchanges with Dave Korn, it seems to me that part > of the problem is that the documentation for > -funsafe-math-optimizations is so vague as to have no discernable > meaning. > > For example, does the wording of the documentation convey the > limitation that one should only invoke math functions with a small > range of arguments (say, -pi to +pi)? I cannot see anything remotely > resembling that limitation, but others can. > > Given that, I wonder how we can tell whether a particular proposed > optimization governed by that flag is permissible. Consider: > > `-funsafe-math-optimizations' > Allow optimizations for floating-point arithmetic that (a) assume > that arguments and results are valid and (b) may violate IEEE or > ANSI standards. > > What does (b) mean? What if anything are its limitations? Is > returning 1.2e27 as the result for a sin() call authorized by (b)? I > would not have expected that, but I can't defend that expectation > based on a literal reading of the text...
I believe that (b) is intended to include: - adding extra precision or range unspecified by the program - spurious overflow and/or underflow - a limited general reduction in precision (no more than a few ulp) - limited ranges of elementary functions - complete loss of precision in unusual cases (where 'unusual' is not well-defined), for instance with complex numbers - applying simplifications to expressions that would be allowable if precision and range were unlimited - all these might vary between compiler versions, so results are not stable and probably many other things that I don't remember right now. The only real limitation on -funsafe-math-optimizations is that it still has to build SPEC.
