Why don't GCC & MSVC optimize based on uninitialized variables? Can I force them to?

Question

Consider some dead-simple code (or a more complicated one, see below¹) that uses an uninitialized stack variable, e.g.:

int main() { int x; return 17 / x; }

Here's what GCC emits (-O3):

mov     eax, 17
xor     ecx, ecx
cdq
idiv    ecx
ret

Here's what MSVC emits (-O2):

mov     eax, 17
cdq
idiv    DWORD PTR [rsp]
ret     0

For reference, here's what Clang emits (-O3):

ret

The thing is, all three compilers detect that this is an uninitialized variable just fine (-Wall), but only one of them actually performs any optimizations based on it.

This is kind of stumping me... I thought all the decades of fighting over undefined behavior was to allow compiler optimizations, and yet I'm seeing only one compiler cares to optimize even the most basic cases of UB.

Why is this? What do I do if I want compilers other than Clang to optimize such cases of UB? Is there any way for me to actually get the benefits of UB instead of just the downsides with either compiler?

---

Footnotes

¹ Apparently this was too much of an SSCCE for some folks to appreciate the actual issue. If you want a more complicated example of this problem that isn't undefined on every execution of the program, just massage it a bit. e.g.:

int main(int argc, char *[])
{
    int x;
    if (argc) { x = 100 + (argc * argc + x); }
    return x;
}

On GCC you get:

main:
    xor     eax, eax
    test    edi, edi
    je      .L1
    imul    edi, edi
    lea     eax, [rdi+100]
.L1:
    ret

On Clang you get:

main:
    ret

Same issue, just more complicated.

Answer 1

Optimizing for actually reading unintiailized data is not the point.

Optimizing for assuming the data you read must have been initialized is.

So if you have some variable that can only be written to as 3 or 1, the compiler can assume it is odd.

Or, if you add positive signed constant to a signed value, we can assume the result is larger than the original signed value (this makes some loops faster).

What the optimizer does when it proves an uninitialized value is read isn't important; making UB or indeterminate value calculation faster is not the point. Well behaved programs don't do that on purpose, spending effort making it faster (or slower, or caring) is a waste of compiler writers time.

It may fall out of other efforts. Or it may not.

Answer 2

Consider this example:

int foo(bool x) {
    int y;
    if (x) y = 3;
    return y;
}

Gcc realizes that the only way the function can return something well defined is when x is true. Hence, when optimizations are turned on there is no brach:

foo(bool):
        mov     eax, 3
        ret

Calling foo(true) is not undefined behavior. Calling foo(false) is undefined behavior. There is nothing in the standard that specifies why foo(false) returns 3. There is also nothing in the standard that mandates that foo(false) does not return 3. Compilers do not optimize code that has undefined behavior, but compilers can optimize code without UB (eg remove the branch in foo) because it is not specified what happens when there is UB.

What do I do if I want compilers other than Clang to optimize such cases of UB?

Compilers do that by default. Gcc is not different than Clang with respect to that.

In your example of

int main() { int x; return 17 / x; } 

there is no missed optimization, because it is not defined what the code will do in the first place.

Your second example can be considered as a missed opportunity for optimization. Though, again: UB grants opportunities to optimize code that does not have UB. The idea is not that you introduce UB in your code to gain optimizations. As your second example can (and should be) rewritten as

int main(int argc, char *[])
{
    int x = 100 + (argc * argc + x);
    return x;
}

It isnt a big issue in practice that gcc doesn't bother to remove the branch in your version. If you don't need the branch you don't have to write it just to expect the compiler to remove it.

Answer 3

The Standard uses the term "Undefined Behavior" to refer to actions which in some contexts might be non-portable but correct, but in other contexts would be erroneous, without making any effort to distinguish into when a particular action should be viewed one way or the other.

In C89 and C99, if it would be possible for a type's underlying storage to hold an invalid bit pattern, attempting to use an uninitialized automatic-duration or malloc-allocated object of that type would invoke Undefined Behavior, but if all possible bit patterns would be valid, accessing such an object would simply yield an Unspecified Value of that type. This meant, for example, that a program could do something like:

struct ushorts256 { uint16_t dat[256]; } x,y;
void test(void)
{
  struct ushorts256 temp;
  int i;
  for (i=0; i<86; i++)
    temp.dat[i*3]=i;
  x=temp;
  y=temp;
}

and if the callers only cared about what was in multiple-of-3 elements of the structures, there would be no need to have the code worry about the other 171 values of temp.

C11 changed the rules so that compiler writers wouldn't have to follow the C89 and C99 behavior if they felt there was something more useful they could do. For example, depending upon what calling code would do with the arrays, it might be more efficient to simply have the code write every third item of x and every third item of y, leaving the remaining items alone. A consequence of this would be that non-multiple-of-3 items of x might not match the corresponding items of y, but people seeking to sell compilers were expected to be able to judge their particular customers' needs better than the Committee ever could.

Some compilers treat uninitialized objects in a manner consistent with C89 and C99. Some may exploit the freedom to have the values behave non-deterministically (as in the example above) but without not disrupting program behavior. Some may opt to treat any programs that access uninitialized variables in gratuitously meaningless fashion. Portable programs may not rely upon any particular treatment, but the authors of the Standard have expressly stated they did not wish to "demean" useful programs that happened to be non-portable (see http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf page 13).