Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!decwrl!borland.com!sjc
From: sjc@borland.com (Steve Correll)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <1991Jun7.204910.878@borland.com>
Date: 7 Jun 91 20:49:10 GMT
References: <9106070109.AA02137@ucbvax.Berkeley.EDU>
Organization: Borland International
Lines: 51

In article <9106070109.AA02137@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
>    2. Appeals to a standard which predates IEEE are not totally con-
>vincing.  What does the Fortran 90 standard say?

The Fortran 90 standard (as of draft S8.115, at least) says the same things
the Fortran 77 standard does with regard to floating point. Fortran existed
long before the birth of IEEE floating point (and will probably exist long
after its death :-)) and the X3J3 committee, being sensitive to the diversity
of floating point implementations, was reluctant to discriminate among them.

A previous posting quoted the Fortran standard somewhat selectively (ANSI
X3.9-1978 sect 6.6.4):

>        ... Once the interpretation has been established in
>        accordance with these rules, the processor may
>        evaluate any mathematically equivalent expression,
>        provided that the integrity of parentheses is not
>        violated.
>
>        Two arithmetic expressions are mathematically
>        equivalent if, for all possible values of their
>        primaries, their mathematical values are equal.
>        However, mathematically equivalent arithmetic
>        expressions may produce different computational
>        results.

The missing rule is (ANSI X3.9-1978 sect 6.6):

    "Any numeric operation whose result is not mathematically defined is
    prohibited in the execution of an executable program. Examples are
    dividing by zero and raising a zero-valued primary to a zero-valued or
    negative-valued power."

Who knows whether IEEE infinity is a "mathematically defined result"? If you
claim that it is, then a compiler which collapses 0*x => x violates section
6.6.4. If you claim that it is not, then a program which even generates IEEE
infinity or NaN (not to mention a program which expects them to propagate
through computations in a well-defined fashion) violates section 6.6. The IEEE
fp committee chose not to deal with existing language standards.

This hasn't prevented lots of people from trying to have their cake and eat
it too, by saying that IEEE floating point should have no impact on compiler
optimization, but the programmer should compute with infinity and NaN anyway,
and it's the programmer's fault if s/he doesn't know that some
IEEE-legal-but-Fortran-illegal features will burn you and others will not,
depending on the implementation in question.

In practice, of course, programmers will attempt to do exactly that, and lots
of them will get burned. You can do useful work with a compiler which doesn't
de-optimize its code to cater to the IEEE standard, but you do need to be
careful about it.