What's wrong with -O3 (optimization level 3)? [duplicate]

Question

I noticed that in QT Creator the default optimization level for the release version is -O2. I was wondering: why not -O3? I've read here on Stack Overflow that it can be dangerous or "bug exposing", but what are those optimizations flag which are considered to be more riskful than helpful and why?

Optimization level 3 flags (on GCC):

• -fgcse-after-reload
• -finline-functions
• -fipa-cp-clone
• -fpredictive-commoning
• -ftree-vectorize
• -funswitch-loops

Answer 1

Aside from compiler bugs, this is probably a myth. It's the -Ofast option that's risky, because that one doesn't even guarantee that standards-complying programs will not break.

Just as a practical example, here's a quick search of libraries, in no particular order, inside the Android Open Source Project (AOSP)—which is probably enough of a "real production codebase"—that use -O3:

cblas, openssh, libmpeg2, libavc, lvvm: MCJIT, jpeg, zlib, lz4, regex-re2, libpng, libutf, (and more)

Other code in the AOSP simply tries to optimize for size (still, Android), so it explicitly uses -Os. But much of that code still uses all these libraries—for which performance is a bigger consideration than size. Notice, too, that correctness is probably a big issue especially for the likes of openssh, which is incidentally mentioned above.

Keep in mind that programmers always tend to get more suspicious of optimized code. When you're not set on writing standards-compliant code, and delve into the territory of undefined & unspecified behavior, there's theoretically nothing to prevent the compiler from generating different results between different configurations (such as optimization level).

So when you mostly do your work on one particular level (debug) you tend to take that as your basic point of reference, and then, when you switch, it's easy to simply blame the optimizer—which, as far as it's concerned, might do a whole lot to remain standards-compliant, unlike our own code.