Path: utzoo!utgpu!watmath!clyde!att!rutgers!ucsd!sdcsvax!ucsdhub!esosun!seismo!uunet!auspex!guy From: guy@auspex.UUCP (Guy Harris) Newsgroups: comp.lang.c Subject: Re: const, volatile, etc [was Re: #defines with parameters] Message-ID: <562@auspex.UUCP> Date: 2 Dec 88 10:52:36 GMT References: <674@quintus.UUCP> <117@halcdc.UUCP> <468@auspex.UUCP> <9016@smoke.BRL.MIL> <10919@ulysses.homer.nj.att.com> Reply-To: guy@auspex.UUCP (Guy Harris) Distribution: eunet,world Organization: Auspex Systems, Santa Clara Lines: 40 >...but what am I to do about fixing all the old stuff that now has >subtle errors caused by optimizations that used to be illegal? Back off on the optimization level, if your compiler will let you? I think the SunOS optimizer is generally "safe" at level -O2 (that's the default level on Sun-4s, and only a very few modules crank it lower - mostly things like bitblt code, not e.g. all the kernel or all the device drivers): -O[level] Optimize the object code. Ignored when either -g, -go, or -a is used. On Sun-2 and Sun-3 systems, -O with the level omitted is equivalent to -O1; on Sun-4 systems, it is equivalent to -O2. on Sun386i systems, all levels are the same as 1. level is one of: 1 Do postpass assembly-level optimization only. 2 Do global optimization prior to code generation, including loop optimizations, common subexpression elimination, copy propagation, and automatic register allocation. -O2 does not optimize references to or defini- tions of external or indirect variables. 3 Same as -O2, but optimize uses and definitions of external variables. -O3 does not trace the effects of pointer assignments. Neither -O3 nor -O4 should be used when compiling either device drivers, or programs that modify exter- nal variables from within signal handlers. 4 Same as -O3, but trace the effects of pointer assignments. I suspect some compilers can be told to back off to a safer level as well.