home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.compilers
- Path: sparky!uunet!usc!sol.ctr.columbia.edu!eff!world!iecc!compilers-sender
- From: eggert@twinsun.com (Paul Eggert)
- Subject: Re: IEEE arithmetic handling
- Reply-To: eggert@twinsun.com (Paul Eggert)
- Organization: Twin Sun, Inc
- Date: Mon, 16 Nov 1992 20:19:55 GMT
- Approved: compilers@iecc.cambridge.ma.us
- Message-ID: <92-11-086@comp.compilers>
- References: <92-11-041@comp.compilers> <92-11-079@comp.compilers>
- Keywords: arithmetic, design
- Sender: compilers-sender@iecc.cambridge.ma.us
- Lines: 35
-
- 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.
- --
- Send compilers articles to compilers@iecc.cambridge.ma.us or
- {ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.
-