Re: IEEE arithmetic handling

jim@meiko.co.uk (James Cownie) writes:


      (I've never seen this handled right in an optimising compilation),


IF (X .ne. X) THEN
print *,'X is a NaN'
ELSE
print *,'X is a number'
ENDIF


GCC 2.3.1 (sparc, -O2) handles this right, for C at least. For example,


int is_NaN(x) double x; { return x != x; }
int iszero(x) int x; { return x != x; }


works as it should: isNaN contains a runtime test, whereas zero yields
0 without a test. Is it really true that most Fortran compilers get
this wrong?


tmb@arolla.idiap.ch (Thomas M. Breuel) writes:


An alternative approach ... is that it is an error to use the
usual language primitives for arithmetic with NaN's.... You
should have to use special IEEE primitives ("is_nan(x)",
"ieee_less(x,y)") to get at the IEEE meanings when available.


The IEEE floating point standard recommends that the user be able to
request a trap whenever operations like .LT. are applied to NaNs, so
for operations like .LT., Breuel's ``alternative approach'' should
simply be a matter of enabling a trap handler. However, .EQ. and .NE.
never trap, so (contra Breuel) Cownie's example still works even if
traps are enabled. See IEEE Std 754-1985, page 13, table 4.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.