Rather, they are getting zealous in eliminating code because of <i>the assumption that there is no undefined behavior</i>. The scope of what undefined behaviors do this is increasing and that breaks programs that make some assumptions on traditional compiler behavior, or that have hidden bugs.<p>I believe that C should have safer semantics, plus standard-defined modes of operation which restore the unsafe semantics selectively.<p>The optimizer then must obey whichever semantics in effect (safer or less safe).<p>Then, in addition to telling your compiler you want a certain optimization level, you could tell it which standard-defined modes of operation you would like.<p>Currently, this is already <i>de facto</i> the case outside of the standard. For instance, users of GCC who want to do certain pointer aliasing without unpredictable behavior tell the compiler to be in a mode in which that is allowed (effectively an altered C dialect) using -fno-strict-aliasing.<p>This kind of thing should be a standard, portable feature. Look, everywhere in this program, I want nice left-to-right evaluation within all expressions and among initializers and function arguments. Except in super-fast.c; when compiling super-fast.c to super-fast.o, please do it in a mode where unspecified-evaluation-order semantics applies and optimize accordingly. (I might even want this on a more finer-grained scale than translation units.)<p>We need safety, and we need to sometimes throw away safe semantics in exchange for better speed (whereby we still ensure that the code we are writing is correct with regard to the weakened semantics; i.e. we promise to the compiler that even if it relaxes the evaluation order, or whatever, we know what we are doing and everything is cool).<p>It would be good to do this without compiler-specific guesswork.<p>Optimization control <i>alone</i> over a language with a single set of semantics (which is largely unsafe) is a bad way to achieve this.