Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!pacbell!rtech!ingres!ingres.com!jpk
From: jpk@ingres.com (Jon Krueger)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <1991Jun10.234313.2157@ingres.Ingres.COM>
Date: 10 Jun 91 23:43:13 GMT
References: <9106070109.AA02137@ucbvax.Berkeley.EDU>
Lines: 73

jbs@WATSON.IBM.COM (James B. Shearer) writes:

> One of the problems with IEEE's infs and
> NaNs is that they do not fit well with fortran.

Is this a problem with IEEE floats or with FORTRAN?

What exceptions for numeric computation would you define?  What
language support would you specify for exception handling?  What
default behaviors would you require at execution time?  What
commercially available environments implement this?  Who has validated
that they do?  For what languages?  On what platforms?

> I think that if a (legal) program behaves differently when compiled with
> and without optimization that then the compiler is broken.  Perhaps you
> disagree.

I take it you are unfamiliar with the concept of ambiguity in language
definition.  It means that a single program can behave in two different
ways without the language definition identifying either one as wrong.
Both ways are perfectly legal according to the standard.  That's why we
call it ambiguous.  The optimizer is free to choose either way without
violating the standard.

I take it you are also unfamiliar with programming language
specifications which identify certain usages as undefined.  The
specification states explicitly that the results are undefined, or not
fully defined.  Programs that use them are not guaranteed to behave the
same way on all compilers conforming to the language specification.
Legal programs can depend on them.  Unwise, perhaps; not very portable,
certainly; but still perfect legal programs in that language.  Again,
the optimizer is free to generate a different behavior from the
unoptimized one.  That this may in some cases be undesirable is not at
issue here.  Providing consistent behavior for these programs falls
under the category of quality of implementation, not standards
conformance.  If inconsistent behavior is encountered here as a
function of level of optimization, we may agree that the implementation
is of poor quality.  But the compiler isn't broken; the code is.

> So how would you code this (detecting whether x inf or NaN)?
>         IF (0.0*X .NE. 0.0)

In FORTRAN, I would code it

      IF (FLTINF(X) .OR. FLTNAN(X))

where FLTINF and FLTNAN are defined as returning true if X is set to
IEEE infinity or IEEE not a number respectively, and false if X is set
to anything else.  I know of no portable FORTRAN expression that can do
this inline.  Implementation of FLTINF and FLTNAN would of course be
system specific.  For instance on SunOS I might implement FLTINF as:

      LOGICAL FUNCTION FLTINF(X)
      REAL X
      IF (X .EQ. r_infinity())
          FLTINF = .TRUE.
      ELSE
          FLTINF = .FALSE.
      RETURN
      END

On lesser operating systems correct implementation of FLTINF would
require dropping into assembler.  This however is an implementation
question for those who maintain FLTINF.  Those who call it may expect
consistent behavior across compilers, operating systems, and levels of
optimization.  I know of no relevant standard which makes the same
guarantees about (0.0*X .NE. 0.0).  Perhaps you could help me by citing
one.  Please explain exactly what it guarantees and where it applies.

-- Jon
--

Jon Krueger, jpk@ingres.com