http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Michael Matz <matz at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Last reconfirmed| |2011-10-14 CC| |matz at gcc dot gnu.org Component|libstdc++ |middle-end Resolution|INVALID | Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #7 from Michael Matz <matz at gcc dot gnu.org> 2011-10-14 15:36:26 UTC --- Hmm. I do sympathise with Ethan. I never was very convinced that __builtin_isnan should return 0 even for NaN bit patterns just because of -ffast-math. After all we don't gain much by this in terms of optimization opportunities (we don't emit calls to it from inside GCC). And Ethan is right that a developer might indeed first test values coming from outside the program for fulfilling the guarantees the program is expecting. After all, -ffinite-math-only is an assertion by the compiler user, but in light of user input he has to first establish these assertions before using code paths that need those assertions. isnan() is precisely the way to establish them. And no, I'm not convinced about the argument that the program author simply shouldn't have used -ffinite-math-only. He can't control user input, or better said, the way he can control it is by the classification functions. Hence we shouldn't remove this (only) way for him to do the classification. Note how I wrote classification. IMO the same applies to isnan, isinf, isnormal, isfinite and fpclassify. Note further that in this light I don't necessarily think that the precise testcase from the initial comment as written there should work. There the NaN isn't coming from user input but is program generated, and for _those_ values the assertion of -ffinite-math-only should already hold. Not that I see any reason to differ between the cases. Reopening as enhancement request as it would be a change in documented behaviour.