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!teddy!panda!talcott!harvard!seismo!brl-tgr!tgr!root%bostonu.csnet@csnet-relay.arpa From: BostonU SysMgrNewsgroups: net.unix-wizards Subject: Optimizing Compilers Message-ID: <6886@brl-tgr.ARPA> Date: Tue, 1-Jan-85 16:37:17 EST Article-I.D.: brl-tgr.6886 Posted: Tue Jan 1 16:37:17 1985 Date-Received: Thu, 3-Jan-85 04:35:45 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 29 Ok, enough of this silliness that an optimizer must NEVER change the effect of a piece of code. Consider the following: for(i=0 ; i < MAX ; i++) x[i] = y/z ; now, obviously y/z is loop invariant... the optimizer decides to compute it once: temp = y/z ; for(i=0; i < n ; i++) x[i] = temp ; reasonable, but what the optimizer does not know is I did a: signal(SIGFPE,print_msg_and_ignore) ; earlier. W/o the optimizer the msg gets printed n times, with it only once. OK, you say, that's a special case of an error. The point is where do you draw the line? Not that an optimizer should NEVER change an effect. -Barry Shein, Boston University