http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724
Bug #: 50724
Summary: isnan broken by -ffinite-math-only in g++
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: e...@andrew.cmu.edu
Given the test code:
static const float f_nan = 0.f/0.f;
const int i_nan = *((int*)(&f_nan));
printf("%g %d %x\n", f_nan, isnan(f_nan), i_nan);
I hope to see:
nan 1 7fc00000
but with the combination of -ffast-math and <cmath>, instead I get:
nan 0 7fc00000
Using just <math.h>, isnan will work. (hence I have filed against libstdc++)
Not surprisingly, adding -fno-finite-math-only can also fix this.
(regarding cmath, both 'isnan' and 'std::isnan' give the same behavior; BTW I'm
a little surprised a unscoped 'isnan' compiles without 'using namespace
std;'... previous gcc (e.g. Apple 4.2.1) required the 'std'. I see cmath
undef's the isnan macro from math.h, so where is the global isnan coming from?)
Tested with 4.4.3 and 4.5.2.
Ironically, a test with 4.1.2 shows the reverse situation: <math.h> didn't work
and <cmath> did work.
I realize the docs for -fno-finite-math-only basically warn "all bets are off"
for NaN handling, but as a quality of implementation issue, I'd like to see
consistent handling for floating-point classification functions. A user may
not care about strict compliance for operations between non-finite values, but
if they are testing for 'bad' values (e.g. isnan), that's probably significant
-- otherwise the user wouldn't have added the classification calls to their
code in the first place.
Alternatively, a warning would be nice, like "isnan always evaluates to false"
when -ffinite-math-only is in effect.
