Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!shelby!unix!garth!fouts@bozeman.bozeman.ingr.UUCP (Martin Fouts) From: fouts@bozeman.bozeman.ingr.UUCP (Martin Fouts) Newsgroups: comp.os.msdos.programmer Subject: Optimization (Was Re: TC++ bug) Message-ID: <648@garth.UUCP> Date: 6 Aug 90 16:11:17 GMT References: <2557@mindlink.UUCP> <2111@cernvax.UUCP> Sender: fouts@garth.UUCP Organization: INTERGRAPH (APD) -- Palo Alto, CA Lines: 34 In-reply-to: antoniop@cernvax.UUCP's message of 23 Jul 90 11:15:31 GMT Having spent some time debugging optimizers, I would like to point out that changing the optimization level changes the semantics of the language being accepted by the compiler and therefor the code generated. A good compiler will document the new assumptions made about code so that a compiler user will be able to determine if they are appropriate for the code being optimized, but all compilers generate code for slightly different languages when the optimizer is on than when it is off. Consider the pre ANSI handling of 'volatile' variables. Turning register optimization on is telling the compiler that you do not use volatile variables and that it can determine the liveness of automatic variables by looking at the local source code. This will break applications which depend on 'volatile' variables which are set outside of the source code. The "Bugs" that ensue usually fall into the niches left by the standards writer for the compiler writer to implement. Often a compiler will handle an implementation defined behavior differently when the optimizer is on than when it is off. This is not a bug, but a feature, since the standard allows the compiler writer to do so. -- Martin Fouts UUCP: ...!pyramid!garth!fouts (or) uunet!ingr!apd!fouts ARPA: apd!fouts@ingr.com PHONE: (415) 852-2310 FAX: (415) 856-9224 MAIL: 2400 Geng Road, Palo Alto, CA, 94303 Moving to Montana; Goin' to be a Dental Floss Tycoon. - Frank Zappa