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.