Does any popular compiler exploit undefined behaviors when optimization is off?

Question

It is claimed in this blog that:

• Undefined behavior only "happens" at high optimization levels like -O2 or -O3.
• If I turn off optimizations with a flag like -O0, then there's no UB.

are both false. I'm wondering if there's any real-world showcase for the claim.

For example, n << 1 triggers UB when n<0. For the following function:

void foo(int n) {
  int t = n<<1;
  if (n>=0)
    nuke();
}

the compiler could compile it cautiously:

void foo(int n) {
  int t = n>=0 ? (n*2) : error("lshift negative int");
  if (n>=0)
    nuke();
}

or normally:

void foo(int n) {
  int t = n*2;
  if (n>=0)
    nuke();
}

or optimize it aggresively:

void foo(int n) {
  // unused
  // int t = n<<1;

  // always true, otherwise UB
  // if (n>=0)
    nuke();
}

Is there any modern popular compiler like gcc/clang that behave in the last way, where some UB not only causes unexpected behavior locally at that statement, but could also be exploited purposely (not considering buffer-overflow attack etc) and pollute the control flow globally, even when -O0 is specified?

Put it simply, are all UBs practically somehow implementation-defined under -O0?

== EDIT ==

The question is not if those claims are theoretically false or nonsensical (because they are). It's whether there's realworld showcase. As @nate-eldredge has rephrased it in the comment:

given some piece of code that is formally UB, a real-life non-optimizing compiler produces results which are particularly surprising (in the way described above), even to a reasonably knowledgeable programmer?

Answer 1

    Undefined behavior only "happens" at high optimization levels like -O2 or -O3.
    If I turn off optimizations with a flag like -O0, then there's no UB.

It is false for one reason. What is undefined in the C language is defined in the C standard. Undefined Behaviour means that from the C language point of view, we do not know how the program will behave. UB does not have to express itself in any particular way - but it is still UB.

Those claims come from not understanding what UB is. UBs do not "happen". They are on the C language level. Even if the program "works fine" it is still UB. As the behaviour is undefined it may stop working if you change the compiler, compiler version, compiler options or run on another OS or hardware.

Answer 2

First let's make it absolutely clear that the blog is correct:

Both statements are false

As user @O___________ also writes in this answer https://stackoverflow.com/a/76720573/4386427 Undefined Behavior is a property of the C source code. No matter what a compiler does the C source code still has undefined behavior. A compiler can't change that.

Then you ask for an example that will surprise (quote): surprising (in the way described above), even to a reasonably knowledgeable programmer

The answer to that must be Such an example doesn't exists

Reason: A "reasonably knowledgeable programmer" knows that it makes no sense to reason about how code with undefined behavior behaves. So a "reasonably knowledgeable programmer" will never be surprised no matter what the resulting program does.

For "less knowledgeable programmers" there may be many examples that could be surprising. For instance:

#include <stdio.h>

int* foo(void)
{
    int x;
    printf("%p\n", (void*)&x);
    return &x;
}

int main(void)
{
    printf("%p\n", (void*)foo());
    return 0;
}

With gcc 12.2 I get:

0x7ffc5981a73c
(nil)

Am I surprised? No, the code has undefine behavior so I don't expect any specific behavior.

Would an unexperienced C programmer be surprised? Perhaps.

Put it simply, are all UBs practically somehow implementation-defined under -O0?

No

"implementation-defined" is something completely different than undefined behavior. An implementation is not required to specify what it will do with code having undefined behavior. It's even allowed to do one thing on mondays, another thing on tuesdays and so on.

"implementation-defined" behavior is something that the implementation must document so that users know what will happen. Two different implementations are allowes to do different things as long as the they document what they do. For code with undefined behavior no documentation is required.

Answer 3

If one were to specify a language "nonBrokenC" which augments the C Standard with the following sentence:

• If parts of the Standard, together with a platform's documentation, K&R1, and K&R2 would describe the behavior of some construct, but some other part of the Standard would characterize the action as undefined, the definition will take precedence.

then most C implementations would be configurable to process nonBrokenC. Compilers may, even with optimizations disabled, vary in things which were never documented in any of the above places, such as how they hold the values of automatic-duration objects whose address is not taken. Thus, for example, something like:

int test1(void)
{
  int x[1],y;
  x[1] = 2;
  return y;
}

might store the value 2 into the storage used to hold y and then return the contents of that storage, but because the address of y is never taken, implementations may even without optimizations enabled decide not to place it on the stack immediately after x.

On the other hand, given something like:

unsigned mul_mod_65536(unsigned short x, unsigned short y)
{
  return (x*y) & 0xFFFF;
}

I would doubt that any compiler for a system with 32-bit two's-complement int type would, unless optimizations or extra diagnostics are disabled, generate code that does anything other than yield the bottom 16 bits of the arithmetic product of x and y, even if that product would fall in the range 0x80000000u to 0xFFFFFFFFu, and would regard any compiler for a 32-bit two's-complement platform where such computation could arbitrarily corrupt memory as untrustworthy even though the Standard had failed to anticipate that compilers for such platforms might behave that way and thus failed to forbid such behavior.