&gt; But ... either the compiler can prove at compile time that the program has undefined behaviour, in which case it should simply refuse to compile, or it can not, in which case it has to emit a runtime check to determine when undefined behaviour &quot;is about to happen&quot;, which is potentially expensive?<p>It&#x27;s more fine-grained: The front end (namely clang in llvm) in easy cases can already see that something is always undefined behaviour and it will omit a warning (for instance through constant propagation). This happens with `i = 32; x&lt;&lt;i` for instance.<p>The optimizer then does stuff like inlining function that lets it see even more places where there sure will be undefined behaviour. This is the point I&#x27;m talking about. The compiler already knows that it will be undefined behaviour - no checks are needed. Performance is of no concern here, as the program already is in a buggy state and may just quit. This will happen when you have the function call f(32) in one function and in `f` there&#x27;s a shift `x &lt;&lt; param`. I believe in this case there will be no compiler warning and the compiler will just optimize out the shift. This is where I think compilers could behave more helpfully.<p>Where performance matters is the case where the compiler doesn&#x27;t know the parameter. To be completely safe the compiler would need to check wether the shift amount is over 31 (`if shamt &gt; 31 { exit(0)} else { x &gt;&gt; shamt }`). Here there&#x27;s also a performance hit in case there is no undefined behaviour occurring.