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 SysMgr 
Newsgroups: 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