But the the author of the original piece is mostly concerned with undefined behavior that can be detected statically - otherwise, compilers would not be able to exploit it to make optimizations.
One thing he mentions is signed integer overflow. This is in the worst case equivalent to the halting problem, but even in practice very hard to test for at compile time.
Another behaviour he mentions is not properly return'ing at the end of a non-void function. This is again technically equivalent to the halting problem, but it is negated by the good practice of making every code path (even potentially dead ones) have a return statement (or throw an exception, etc.) Go takes this approach if I remember correctly.
It can't always be tested for at compiler time but the problem he's complaining about is when C compilers do detect signed integer overflow. What happens is that someone writes code that in practice handles signed integer overflow fine, then a while later the C compiler developers get clever, detect the integer overflow, and decide to optimize that code away because it's invoking undefined behaviour and they can do whatever they like. The code in question is frequently security-critical, so by removing it the compiler converts safe code whose behaviour is technically undefined by the standard into a security vulnerability.
The common case is (probably) not that a compiler detects an instance of signed over/underflow. Instead, it can assume that this never happens and generate "dangerous" code.
Another behaviour he mentions is not properly return'ing at the end of a non-void function. This is again technically equivalent to the halting problem, but it is negated by the good practice of making every code path (even potentially dead ones) have a return statement (or throw an exception, etc.) Go takes this approach if I remember correctly.