Specifically, implement UB the way it is described in the standard: pretend it isn't UB, do it anyway, consequences be damned. That's what "ignore the situation with unpredictable results" actually means.
The current standard is _very_ explicit that undefined behavior is indeed undefined, i.e. "do whatever you want".
> pretend it isn't UB, do it anyway, consequences be damned.
This explicitly isn't a requirement, but even if it were, "ignoring the situation completely with unpredictable results" can be interpreted in numerous ways. One of these ways is "ignoring any cases in which UB is encountered" which is exactly what compilers are doing. Then again, saying "the compiler didn't ignore the situation and as a consequence I got results I didn't predict" isn't a strong argument when the standard specifically told you that you will get unpredictable results.
There's a certain poetic consistency in ignoring arbitrary portions of the standard to justify ignoring arbitrary portions of the input code.
Saying that compilers shouldn't ignore code with undefined behavior is like saying compilers shouldn't ignore the body of an if-statement just because the condition evaluated to false.
And because it is explicit—a fact you yourself just admitted—the fact that silent erasure of non-dead code is not a listed option in response to UB means that it is not allowed.
No reasonable person can say that it is explicit. It simply, factually, is not. At no point in any version of the C Standard does the text "implementations can do whatever they want" appear.
I have no time for blatant and insulting dishonesty. We're done here.
behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements"
It is _very_ explicit. The following note is (as all notes are) not normative. So even if the note would cast any doubt (it really doesn't), it can safely be ignored.