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.