Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!oddjob!mimsy!eneevax!umd5!uvaarpa!mcnc!rti!sas!bts
From: bts@sas.UUCP (Brian T. Schellenberger)
Newsgroups: comp.lang.c
Subject: Re: Optimization (was Re: volatile)
Message-ID: <474@sas.UUCP>
Date: 23 Apr 88 19:45:09 GMT
References: <13074@brl-adm.ARPA>
Reply-To: bts@sas.UUCP (Brian T. Schellenberger)
Organization: SAS Institute Inc, Cary NC
Lines: 37

In article <13074@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes:
|Terry Lambert writes:
|>Basically, if it works without -O, it should work with -O, regardless of what
|>the compiler writer's optimization does to achieve its goal.  If this makes
|>writing compilers harder, so what?
|
|This bears repeating.  There should be no circumstances under which
|the semantics of the language are changed by a flag to the compiler.

These two things are by no means the same.  Yes, turning on optimization should
not change any of the *defined* semantics of the language.  On the other hand,
it must change *some* behavior.  I mean, if you happen to know that your 
compiler store constants > 255 in a certain place, and you change the place
to change the value of "1024", then I think it reasonable for your code to
break when optimized (by, say, shifting) even it works when not optimized.

Similarly, timing loops will surely break with optimization; who could expect
otherwise?  If optimize must keep the space and time and memory layout the
same, it's not able to do much.

The question then becomes one of degree:  I consider it unreasonable for the
compiler to optimze my entire program to a no-op because it concludes the whole
thing is pointless (the Apollo 9.7 C compiler does this for some code!),
whereas I consider it quite reasonable for it to speed up timing loops.

ANSI is trying to define exactly where to draw those lines.  Those things 
guaranteed in ANSI must work regardless of optimization or target machine;
those things not defined may break in some places.  If you don't like where
the line is drawn, complain, but arguing that the line should not exist is 
silly.

And anyway, you can always compile with minimal optimization if you find doing
really unreasonable things makes you happy.
-- 
                                                         --Brian.
(Brian T. Schellenberger)				 ...!mcnc!rti!sas!bts

. . . now at 2400 baud, so maybe I'll stop bothering to flame long includes.