Without strict aliasing? Generally, I think strict aliasing is a fine thing. It would have been nicer to have "restrict" be the default and "alias" being an

Without strict aliasing? Generally, I think strict aliasing is a fine thing. It would have been nicer to have "restrict" be the default and "alias" being an optional specifier, but likely there was no way to do this without breaking too much existing code. Warnings are often nice, but I don't recall having any issues with compilers optimizing based on assumptions of lack of aliasing. especially of templated code like the STL in C++ I'm an opinionated C programmer, but have no opinion of how C++ should handle things. I'm only considering the impact on C. If the STL requires an unfriendly C++ compiler, I'm OK with that, but this doesn't affect my thinking about C compilers. However, the only—or at least the easiest—way the compiler can tell that this is the case is by observing that, for example, a null pointer would have to be dereferenced to get to that dead code. Or, for example, that a signed integer addition would have to overflow. Or a full-width shift. Or a variety of other things that have a might make sense in both the programmers mental model and on the processor on which the compiled program will be run. Therefore the compiler is doing you a favor by eliminating that obviously dead code. Do you really believe that the compiler is doing you a favor by silently removing a check for signed integer overflow that you explicitly included? If so, we have found (at least one of) the point(s) of our disagreement! If on the other hand you feel that removing security related error checking is an unfortunate negative consequence of a necessary optimization, perhaps we can find a way to mitigate the consequences?