Unfortunately, `-O0` doesn't actually disable all optimizations. It probably disables any that would affect this though.

There are many optimizations that a compiler can perform without relying on the optimization level to determine how to pervert your program that day. If different optimization levels produce different results that is bad thing, something to be avoided, not encouraged.

If it is really necessary to generate random code when some anomalous situation is encountered, that should be a special option to enable dangerous non-deterministic if-you-made-a-mistake-we-will-delete-parts-of-your-program type behavior. I wouldn't consider that optimization though, more like disabling all your compiler's safety features.

Which optimizations?

Loop unrolling for loops that have a static or range bounded number of iterations is a good example. Others include constant expression evaluation, dead code elimination, common subexpression elimination, and static function inlining.

If you fold float expressions at compile time you will get different results than runtime if the program has changed the fpu control word.

People complain about dead code elimination all the time when we have these discussions.

Inlining break code that try to read the return address off the stack frame or that make assumptions about stack layout.

Loop unrolling might change the order of stores and load, which is visible behaviour if any of those traps.

I assure you that for each optimization, no matter how trivial, it will break someone code