:> > I always figured it to turn off the optimizer for one out of a hundred :> > files was a lot easier than some of the code contortions people would :> > write for the sake of "hand-optimizing". :> :> I find this difficult to understand. If you understand in detail all the bugs :> in your compilation system and you have tools to inspect your source code so :> that you can identify any files that might suffer from the bugs, then perhaps :> I /would/ agree. My experience is different. Compiler bugs tend to be :> pathelogical, otherwise they would have been found before and fixed (I'm an :> optimist). Often they cause the code to behave oddly under obscure situations :> which, sadly, don't always get tested. If an optimiser significantly :> increases the incidence of latent bugs, that is bad news. But when it's less than one percent, AND you have adequate testing, my "personal" process was that when I traced a bug to a particular unit, I would try it with that unit "unoptimized". If the bug went away, announce "fixed". :> Our systems here are built from many hundreds of files. Productivity :> requirements lead us to adopt an approach to the building of these systems :> which is sytematic and largely mechanised. Special cases, such as supressing :> the optimiser, are not welcome, and hence my comment earlier about the need :> for tool support. Our system was about five million Ada statements. In order to speed up compilation, we (not I personally) wrote "wrapper" tools to call the compiler. The wrapper would farm out the compilations to different hosts in parallel. Since that meant that the wrapper was called for EACH file, it would have been no problem for the wrapper to check some Configuration Management file for the correct optimization level. In our case, even that would not be necessary, since the compiler itself created/updated/used an "options" file which told it the optimization level to use for each file. We even had one and only one source file that would crash the compiler if we used an optimization level other than ONE. (Zero was no optimization, one was minimal, two through nine provided greater optimization.) I should also clear up something else: I said that the Verdix optimizer had bugs which affected less than one percent of source files. I should have also mentioned that most of the bugs aborted the compilation; only a few actually generated bad code. We are straying off the charter of this list, though, so if you wish to continue discussing it, I'd suggest direct email. --------------------------------------------------------------------------- W. Wesley Groleau (Wes) Office: 219-429-4923 Hughes Defense Communications (MS 10-41) Home: 219-471-7206 Fort Wayne, IN 46808 (Unix): [log in to unmask] ---------------------------------------------------------------------------