Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!munnari.oz.au!bruce!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <6478@goanna.cs.rmit.oz.au>
Date: 24 Jun 91 09:51:00 GMT
Article-I.D.: goanna.6478
References: <9106190124.AA27410@ucbvax.Berkeley.EDU> <1991Jun22.003029.16748@watson.ibm.com>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 33

In article <1991Jun22.003029.16748@watson.ibm.com>,
prener@watson.ibm.com (Dan Prener) writes:
> As immodest as it might be for me to agree with my colleague, I must
> agree with James Shearer.  Indeed, the spirit of FORTRAN is, overwhelmingly,
> that a program whose behavior is changed by optimization is not a legal
> program.

In that case, a subroutine like	
	SUBROUTINE FOO(X, A, B, C)
	    REAL X, A, B, C
	    X = A*B + A*C
	END
must not be legal.  Darn it, I used to _like_ Fortran.  (Yes, optimisation
_may_ change the behaviour of this program in a signficant way.)  Perhaps
more obviously,
	SUBROUTINE FOO(X, A, B, C)
	    REAL X, A, B, C
	    X = A*B
	    X = X + A*C
	END
may _also_ have its behaviour changed by certain optimisations.  (Hint:
Sun's compilers have a command-line flag related to this one.)  The use
of parentheses won't help here.

The moral of the story is that the values and operations provided by
floating-point hardware _apprximate_ that values and operations of
real arithmetic, but do not obey the same laws, so that a language which
licences transformations which are valid for the reals but invalid for
the floats is a language which licences a compiler to produce different
numeric results (possibly HUGELY different) depending on optimisation
level.
-- 
I agree with Jim Giles about many of the deficiencies of present UNIX.