[Bug 294692] lib/msun: Replaced manual checks with isnan()

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D294692

--- Comment #9 from Robert Clausecker <[email protected]> ---
(In reply to Steve Kargl from comment #6)

I think the whole spiel about =E2=80=9Cwhat if somebody builds libm with -f=
fast-math?!=E2=80=9D
is not productive.  Do you suggest we should continue to generate really bad
code in the default case, just to support building libm with -ffast-math, w=
hich
isn't supported in any case right now?  I don't quite get how it is relevant
what happens when these files are built with -ffast-math.  We don't build w=
ith
-ffast-math, and that option is known to generate wrong code, so why should=
 we
care?

> I believe the check for NaN of a long double looks more
> complicated because the bit twiddling needs to deal with
> the 'hidden bit' for LD80, which is explicitly set in
> the significand.

Ok that makes sense, I didn't clue in on the two numbers having different
types.

So overall LGTM from my side.

> Is it because isnan(x) can be expanded to x !=3D x and it can be optimize=
d away? If that's the case, shouldn't we reconsider how we define isnan(x)?

That definition is actually wrong these days I think as x !=3D x triggers
FE_INVALID on sNaN, which isnan(x) should not.  There is a compiler built-i=
n we
use for isnan(x), which does the right thing.  I think we should remove the
inline definitions from math.h, as they do more harm than good.

--=20
You are receiving this mail because:
You are the assignee for the bug.=