Undefined behavior doesn't state anything bout legality; only that the ISO C standard (whichever version applies) doesn't provide a requirement on what the behavior should be.

Firstly, that doesn't mean there doesn't exist any requirement; implementations are not only written to ISO C requirements and none other. ISO C requirements are only one ingredient.

Secondly, compilers which play games like what you describe are not being earnestly implemented. If a compiler detects undefined behavior it should either diagnose it or provide a documented extension. Any other response is irresponsible. The unpredictable actual behaviors should arise only when the situation was ignored. In fact it may be outright nonconforming.

The standard says:

"Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."

A possible interpretation of the above statement is that the unpredictable results occur only if the undefined behavior is ignored (i.e. not detected).

If some weird optimizations are based on the presence of undefined behavior, they are in essence extensions, and must be documented. This is because the situation is being exploited rather than ignored, and the program isn't being terminated with or without a diagnostic. That leaves "behaving in a documented manner".

But optimizing based on explicitly detecting undefined behavior is not a legitimate extension. It is simply insane, because the undefined behavior is not actually being defined. There is no extension there, per se. Optimization requires abstract semantics, but in this situation, there aren't any; the implementation is taking C that has no (ISO standard) meaning, it is not giving it any meaning, and yet, it is trying to make the meaningless program go faster. Doing all this without issuing a diagnostic is criminal.

I don't think the GCC people are really doing this; only people think that. Rather, they are writing optimizations which assume that behavior is not undefined, which is completely different. The potential there is to be over-zealous: to forget that GCC is expected to be consistent from release to release: that it preserves its set of documented extensions, and even some of its undocumented behaviors. Not every behavior in GCC that is not documented is necessarily a fluke. Maybe it was intentional, but failed to be documented properly.

Compiler developers must cooperate with their community of users. If 90% of the users are relying on some undocumented feature, the compiler people must be prepared to make a compromises. Firstly, revert any change which breaks it, and then, having learned about it, try avoid breaking it. Secondly, explore and discuss this behavior to see how reliable it really is (or under what conditions). See whether it can be bullet-proofed and documented. Failing that, see if it can be detected and diagnosed. If such a behavior can be detected and diagnosed, then it can be staged through planned obsolescence: for a few compiler releases, there is an diagnostic, but it keeps working. Then it stops working, and the diagnostic can change to a different one, which merely flags the error.

The authors of this proposal agree, and are trying to avoid such situations by just eliminating undefined behavior. Their blog posts and academic papers (linked from the blog post in this submission) have many examples where such insanity has happened.