Newsgroups: comp.arch
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!rice!rutherfordia.rice.edu!preston
From: preston@rutherfordia.rice.edu (Preston Briggs)
Subject: Re: IEEE floating point (Goldberg paper)
Message-ID: <1991Jun8.162929.24083@rice.edu>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
References: <9106080100.AA09901@ucbvax.Berkeley.EDU>
Date: Sat, 8 Jun 91 16:29:29 GMT

jbs@WATSON.IBM.COM writes:

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

>It works fine when compiled on other machines (with
>and without optimization).  It works fine when compiled with your
>compiler without optimization.  However it fails when compiled with
>your compiler with optimization.  I believe it will difficult to con-
>vince this user that the bug is in his package and not in your compiler
>whatever the technical validity of your position

Often, compiler and machine differences expose "implementation dependencies"
in programs.  These are sometimes marked as "implementation dependent"
in the language spec, but programmers _will_ play with fire.
Alternatively, some language specs say things like:
"the behaviour of a program doing thus-and-so is undefined."

Compiler writers are free to make use of these "don't cares" to
simplify their lives and/or speed the object code.

I agree that it's difficult to convince users of this,
but a baseball bat often suffices.  Alternatively, pointing
out the problem in the code, along with the relevant portion of
the manual sometimes suffices.  The behaviour of a program
other machines or with other compilers or simply with the optimizer
turned off is not sufficient reason to convict the optimizer.

Preston Briggs