4 ms·

Because -O3 enables optimizations that break code with some lesser known cases of UB[1]. So people just don't enable -O3 because they can't be bothered to fix U

Because -O3 enables optimizations that break code with some lesser known cases of UB[1]. So people just don't enable -O3 because they can't be bothered to fix UB in their codebase, or because they think it's a "compiler bug". There are other reasons for not using -O3 which people already mentioned. As a matter of fact, Gentoo specifically says in their docs that -O3 breaks some packages[2]. [1] https://stackoverflow.com/questions/57889116/different-evaluation-when-compiling-with-o3 https://stackoverflow.com/questions/57889116/different-evalu... [2] https://wiki.gentoo.org/wiki/GCC_optimization#-O https://wiki.gentoo.org/wiki/GCC_optimization#-O

gpderetta 3y ago
UB-breaking optimizations are already enabled at O1. I don't think -O3 is particularly noticeable for that: your first link shows code that breaks between O3 and no optimization at all. O3 does more aggressive inlining and generally expensive optimizations and optimizations that are not necessarily profitable.
- qweqwe14 3y ago
  I was only saying that -O3 enables _even more_ optimizations, which can lead to UB code that works with -O2 but misbehaves on -O3. And because -O3 is seldom used (for reasons other than code breakage), the code patterns that are actually UB but don't get compiled to bad code at -O2 (by e.g. gcc) are lesser known. It all depends on how much a given compiler is willing to make assumptions based on UB and what's permitted by C spec to make optimizations. At -O3 it probably makes a lot more of those assumptions, along the lines of "the spec says this is undefined behavior so I will assume it can never happen and optimize it based on that". The more aggressive inlining in conjunction with that probably exposes more even more UB. Edit: found example where code works on -O2 but breaks on -O3, related to using abnormal amounts of stack space https://stackoverflow.com/questions/47058978/g-optimization-o2-flag-fixes-a-broken-code-where-o3-breaks-it-again https://stackoverflow.com/questions/47058978/g-optimization-...
jandrese 3y ago
Isn’t the warning that -O3 might break stuff horribly obsolete? It was an issue in 2.95, but that was many years ago.

gpderetta 3y ago

UB-breaking optimizations are already enabled at O1. I don't think -O3 is particularly noticeable for that: your first link shows code that breaks between O3 and no optimization at all. O3 does more aggressive inlining and generally expensive optimizations and optimizations that are not necessarily profitable.

qweqwe14 3y ago
I was only saying that -O3 enables _even more_ optimizations, which can lead to UB code that works with -O2 but misbehaves on -O3. And because -O3 is seldom used (for reasons other than code breakage), the code patterns that are actually UB but don't get compiled to bad code at -O2 (by e.g. gcc) are lesser known. It all depends on how much a given compiler is willing to make assumptions based on UB and what's permitted by C spec to make optimizations. At -O3 it probably makes a lot more of those assumptions, along the lines of "the spec says this is undefined behavior so I will assume it can never happen and optimize it based on that". The more aggressive inlining in conjunction with that probably exposes more even more UB. Edit: found example where code works on -O2 but breaks on -O3, related to using abnormal amounts of stack space https://stackoverflow.com/questions/47058978/g-optimization-o2-flag-fixes-a-broken-code-where-o3-breaks-it-again https://stackoverflow.com/questions/47058978/g-optimization-...

jandrese 3y ago

Isn’t the warning that -O3 might break stuff horribly obsolete? It was an issue in 2.95, but that was many years ago.