Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!mit-eddie!godot!harvard!seismo!brl-tgr!tgr!boyle@ANL-MCS.ARPA
From: boyle@ANL-MCS.ARPA
Newsgroups: net.unix-wizards
Subject: Re:  smart compilers
Message-ID: <6684@brl-tgr.ARPA>
Date: Thu, 20-Dec-84 09:26:42 EST
Article-I.D.: brl-tgr.6684
Posted: Thu Dec 20 09:26:42 1984
Date-Received: Sun, 23-Dec-84 01:39:42 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 16

The view "If optimizing breaks programs which conform to the language
definition, the optimizer is broken" is not universally held.  For
example, on the IBM Fortran H compiler (and probably also on
H-extended), if you wrote a loop with an if test to protect against
division by zero, and if the expression controlled by the if (the
expression with the divide) were constant with respect to the loop, it
would be moved out of the loop, *but the test would not*.  Hence the
optimized program would divide by zero where the unoptimized one would
not.  The Fortran Programmer's Guide even contained the statement that
"the program may not behave the same after optimization as before".

I never understood why they didn't optimize all programs to a return
instruction, so at least they would have been fast!
					Jim Boyle
					Math. and Comp. Sci. Div.
					Argonne Nat'l Lab.