On Sun, Apr 11, 2010 at 1:39 AM, Chris Pickett <[email protected]> wrote: > On Mon, Apr 5, 2010 at 9:33 PM, Glenn Fowler <[email protected]> wrote: >> >> here is some example code that shows what ksh93/ast use for printing nan >> on systems that support both isnan() and signbit() >> --- >> #include <stdio.h> >> #include <math.h> >> int >> main() >> { >> long double v; >> long double z = 0.0; >> >> v = z / z; >> printf("isnan=%d signbit=%d %Lg\n", !!isnan(v), !!signbit(v), v); >> v = -v; >> printf("isnan=%d signbit=%d %Lg\n", !!isnan(v), !!signbit(v), v); >> return 0; >> } >> --- >> from a few tests it seems that it may be an x86 issue >> for the ast stdio >> on non-x86 systems >> isnan=1 signbit=0 nan >> isnan=1 signbit=1 -nan >> and on x86 systems (linux solaris) >> isnan=1 signbit=1 -nan >> isnan=1 signbit=0 nan > > I knew Intel can't do math :) > I still think this needs to be corrected at compiler level. Just > because the hardware is broken doesn't mean the software can't work > around it.
I agree. Does anyone from the Sun Studio team wish to comment about this here or should I go ahead and escalate the issue with priority? > We're now replacing (( x==nan )) with (( x==nan || x=-nan )) as > workaround. *PAIN* With ksh93t and ksh93t+ you can use (( isnan(x) )) instead. Irek _______________________________________________ tools-compilers mailing list [email protected]
