I really think that undefined behaviour should be switched to machine-dependent behaviour everywhere and we should just have tools that can suggest optimized variants of hot functions - to be rewritten in ways that take advantage of assuming undefined behaviour doesn't happen. Or lift the `extern "lang"{}' construct from C++ to C and have `extern "C-strict"' which turns on full strict undefined behaviour optimizations. Yes, I know I can turn most of them off. We ship C++ software and always compile with singed-overflow enabled and strict-aliasing disabled (among others). Those are just too dangerous to be turned on for an entire codebase of a large C++ application where you have no idea what will be inlined where and what LTO will do. But if some UB allows for measurable performance gains, we should be able to turn it back on for restricted safe scopes.

And please, if the compiler can prove that the program invokes UB in "strict-UB" mode, that should be an error, not a cause for the code to be deleted. I'm talking about the case of this SPEC 2006 code [1]

It doesn't make sense to me to just apply potentially disastrous micro-optimizations that save a couple of percent of run-time on the whole program. This sounds like a classic case of optimizing before measuring.

1 https://blog.regehr.org/archives/918