Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cis.ohio-state.edu!ucbvax!WATSON.IBM.COM!jbs
From: jbs@WATSON.IBM.COM
Newsgroups: comp.arch
Subject: IEEE arithmetic
Message-ID: <9106150206.AA15019@ucbvax.Berkeley.EDU>
Date: 15 Jun 91 01:45:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 32


         I said:
>Perhaps I should have said it is undesirable for a program to behave
>differently when compiled with and without optimization regardless
>of whether this is technically permitted by the standard.  (Actually
>I think it would desirable for the standard to exactly specify the
>behavior of any legal program but apparently it does not.)
         David Boundy said:
Undesirable, yes.  But also unavoidable in a market where performance
is what sells machines.

         Unavoidable is too strong.  I believe there are compilers
(such as xlf) for which compiling with optimization does not change
the behavior of legal programs.
         David Boundy said:
                                                                Thus,
standards do "exactly specify the behavior of any legal program:"  that's
the defintion of a "legal program."

         I believe this is incorrect.  If I write x=a+b+c and the stand-
ard does not specify the order of evaluation then the compiler is free
to evaluate it as (a+b)+c or as a+(b+c) (or according to some in either
way depending on the optimization level).  Thus the behavior of the pro-
gram is not exactly specified.
         David Boundy said:
           ( There's the issue that on our 68000 machines, we do arithmetic at
compile time in 64 bits, but the same expression unoptimized will be evaluated
at run time in 80 bits.  Sigh. )

         Well if the behavior of any legal program is exactly specified
how can this sort of thing occur.
                          James B. Shearer