Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!hp4nl!cwi.nl!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <3653@charon.cwi.nl>
Date: 9 Jun 91 01:08:36 GMT
References: <9106070109.AA02137@ucbvax.Berkeley.EDU> <26665@as0c.sei.cmu.edu>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 35

Aren't we getting a bit confused?  There are (in this case) two standards.
The first one is the language standard, the second is the IEEE standard for
floating point arithmetic.  Now we find:

In article <9106070109.AA02137@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
 >         Do you replace 0*x with 0 when compiling without optimization?
 > I think that if a (legal) program behaves differently when compiled with
 > and without optimization that then the compiler is broken.  Perhaps you
 > disagree.
It is perfectly allowed for a program to behave differently with optimization
if the program goes beyond what the language standard prescribes.  However,
in this case the compiler can not claim to be IEEE conformant (and should say
so) even if the box it runs on is IEEE conformant.

In article <26665@as0c.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
 > >        IF (0.0*X .NE. 0.0)
 > >        So how would you code this (detecting whether x inf or NaN)?
 > At the correct level of abstraction.  At the Fortran level, the
 > abstraction is that of the real numbers - as is made clear in the
 > standard.  At that level, NaNs don't exist, so you can't look for
 > them.
 > 
Unless the compiler claims to fully support the arithmetic of the box it runs
on.  In that case it should be IEEE conformant, and hence not optimize such
expressions.

(write a routine:)
 > 	LOGICAL FUNCTION ISANAN(X)

Certainly if you want to be portable and have your program run with
1.  compilers that are not IEEE conformant, and/or
2.  boxes that are not IEEE conformant.
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl