Perhaps what we really want is a flag to cause the compiler to error for code that would produce undefined behavior and give warnings for the rest? Turning all warnings into errors is a great "worse is better" technique but it seems a bit too coarse-grained to me.
Oh, to be sure! However, my claim is that if compiler authors are able to add more no-false-positives undefined behavior warnings over time, I kinda want those to "break" the build for my existing software... But if something is just a style check or creates false results, I'd rather the build be allowed to happen.
Yes, an interpreter has a much better shot at detecting runtime undefined behaviour than a compiler.
The whole point of undefined behaviour in C and C++ is to let the compiler cheat: ie a Java or Haskell compiler would have to take into account that (i < i + 1) can sometimes be wrong for native ints, and would have to prove that overflow can't happen in order to optimize this comparison away to True. Undefined behaviour in the standard frees C and C++ compilers from these obligations, and they can just assume overflow for signed ints won't happen.
These shortcuts (plus a lot of smarts) make it feasible to write a fast optimizing compiler with the 1970s state of the art in static analysis.
Just FYI, not all undefined behaviour can be detected at compile time using current C semantics. I'm very very in favour of cracking down on undefined behaviour and changing things from undefined to implementation-defined and stuff like that, but it's not as easy as just flicking a switch and making the compiler warn whenever it assumes undefined behaviour won't happen.
