> This won't break the code. But I'm saying that if the compiler assumes > wrapping, even in some particular cases (e.g. code that *looks like* > "overflow check"), it could miss some potential optimizations. That > is, it is not possible to avoid breaking overflow checks *and* > optimizing everything else.
Certainly. Indeed I think that's the whole point of this thread: that if you want to catch ALL potential optimizations opportunities given to you by the standard, you must assume that signed overflows are undefined. However, what's being discussed is an engineering tradeoff where you give up SOME optimization opportunities to avoid breaking code. Essentially, there are three choices: with -fwrapv, you must preseve wrapping semantics and do NONE of those optimizations; with -fno-wrapv, you can do ALL of them; in the default cause, a heuristic can be used that attempts to balance optimization quality against breakage of old code.