http://blog.llvm.org/2011/05/what-every-c-programmer-should-...:

> warning: after 3 levels of inlining (potentially across files with Link Time Optimization), some common subexpression elimination, after hoisting this thing out of a loop and proving that these 13 pointers don't alias, we found a case where you're doing something undefined. This could either be because there is a bug in your code, or because you have macros and inlining and the invalid code is dynamically unreachable but we can't prove that it is dead.

That is intrinsically limited because UB are runtime issues (otherwise they'd be compiler errors) and the compiler simply assumes they don't happen, plus many of the "UB-related" optimisations (in the sense that these optimisations change the behaviour of non-well-formed programs) are surfaced by other optimisations (largely inlining).

Problem is there are a lot of cases where the compiler doesnt know if the undefined behavior would happen in the real world. That is there is undefined behavior if some input parameter is out of range, and no way for the compiler to know that the input will always be in range - something I as a programmer with more global knowledge knows for sure which is why I don't check it.

clang has UBSan, which adds runtime checks for detecting various kinds of undefined behaviour: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

Luckily, compiler authors have gotten the message and are starting to improve on this situation slowly.

Gcc already (gcc-8) reports possible undefined behavior for loops and these are mostly out-of-bounds in my code. I like that a lot, actually, it save a ton of time.