The problem, as I&#x27;ve heard it, is that all but the most trivial instances of statically detectable UB are only noticeable once optimizations have been performed (or simulated by an analyzer), and at that point they&#x27;re indistinguishable from potential UB introduced by the optimizations themselves.<p>The compiler does a bunch of inlining, constant propagation, other optimizing transformations... and it ends up with some code paths that statically represent UB. If the original code couldn&#x27;t display UB (up to the user to get this right), and the transformations preserve the original code&#x27;s defined behavior (as of course they should), then it&#x27;s safe to exploit the fact that these paths are impossible for further optimization or dead code elimination.<p>Reversing layers of optimization to decide &quot;Is this UB something introduced by me or by the user?&quot; is not something compilers are traditionally architected to do, nor can they typically perform the analysis necessary to determine if a UB code path from either source is guarded by some high level invariants.<p>In such cases, warnings would be actively harmful, as they&#x27;d suggest unneeded corrections.