http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Ethan Tira-Thompson <ejtttje at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
--- Comment #14 from Ethan Tira-Thompson <ejtttje at gmail dot com> 2011-10-15
14:01:11 UTC ---
Richard said:
> The documentation states
> "Allow optimizations for floating-point arithmetic that
> assume that arguments and results are not NaNs or +-Infs."
Yes, that's my argument as well. Note ARITHMETIC. Also note MATH in the name
of both --finite-MATH-only, and -ffast-MATH it falls under. And it doesn't
reference the 'math library' to qualify that.
Basically, if you want to close on this point, I want to see you explicitly
argue why the classification functions should be considered arithmetic.
I'm going to nail this down and list there are 5 classification functions
(fpclassify, infinite, isinf, isnan, isnormal) and the vast majority of the
other library functions are obviously proper arithmetic operations. The ones
that aren't (signbit, copysign, nextafter, nan), you're exactly right that we
should carefully consider the result of NaN optimization ("special cases").
You don't have to do this if *you* don't want to, but it should be done and it
sounds like no one has.
> This has been discussed to death already, and the present behavior is how
> GCC behaved since ever.
Except also NOT TRUE. It currently doesn't behave this way with math.h. It
didn't behave this way in 4.1 (Fedora) or 4.2 (Apple). I only got screwed by
this by the CHANGE in behavior on upgrading to 4.4. (Not sure about 4.3). I
already presented this in the original post at the top (except the Apple test
is a new data point; FYI Apple gcc math.h also 'works', so either 4.2 was
generally consistent or Apple likes to patch theirs for consistency)
This is further evidence gcc has not had a good policy discussion of where NaN
optimizations should be applied, because the implementation keeps changing, and
it's not even consistent between math.h and cmath within any given version
other than 4.2-Apple.
Marc said:
>> __FINITE_MATH_ONLY__
> Not very portable afaik.
Neither is -ffast-math, add a 'defined(__FINITE_MATH_ONLY__) &&' and it will be
applied opportunistically when available, or even better: the user can
-D__FINITE_MATH_ONLY__=1 themselves on non-gcc platforms and still get the
performance benefit you're looking for even without -ffast-math support, so
it's a double win. IMHO, on the other hand it's harder and more error prone to
override isnan with my own implementation.
