3 ms·

Thanks for looking into the history! Interesting to see that this wrong-headed behavior has now been around in GCC for longer than the status quo before. Other

Thanks for looking into the history! Interesting to see that this wrong-headed behavior has now been around in GCC for longer than the status quo before. Other compilers are different though - MSVC only seems to have started optimizing around this in ~2016 or so, icc seems to have done something around this in 2020, and I'm sure many embedded compilers ignore it even today. I couldn't find anything definitive on clang, but given its history I assume it probably always enforced this mistake. I'd also note that several major C programs only work when signed integer overflow is defined: I mentioned Linux previously, but Python is another one. And Chrome and Firefox are considering enabling -fwrapv and equivalents.

deleted 3y ago
[deleted]
trealira 3y ago
Yeah, you're definitely right that a lot of C and C++ code is written assuming signed overflow won't be optimized away. I think it was a mistake of GCC to do this optimization without some explicit flag like "-fremove-signed-overflow". I wish they didn't do that, but it's not up to me what they do. It's necessary for optimizations like loop unrolling, auto-vectorization, and compiling "for (int i = 0; i < N; i++)" as if it were written "for (size_t i = 0; i < N; i++)" when it's more efficient to do so, but again, I think this should be opt-in, and either -fwrapv or -ftrapv should be default on the generic -O1, -O2, -O3 levels.