Does C++ allow an optimizing compiler to ignore side effects on the for-condition?

Question

While debugging some legacy code I stumbled upon surprising (for me) compiler behavior. Now I'd like to know whether any clause in the C++ spec allows the following optimization, where side effects from a function call on the for-condition are ignored:

void bar() 
{
   extern int upper_bound;
   upper_bound--;
}

void foo()
{
   extern int upper_bound; // from some other translation unit, initially ~ 10
   for (int i = 0; i < upper_bound; ) {
      bar();
   }
}

In the resulting dissambly there is a control path in which upper_bound is preserved in a register and the decrement of upper_bound in bar() never takes effect.

My compiler is Microsoft Visual C++ 11.00.60610.1.

Honestly I don't see much wiggle room in 6.5.3 and 6.5.1 of N3242 but I want to be sure that I'm not missing something obvious.

Answer 1

The standard clearly and unambiguously clarifies that the two declarations of upper_bound refer to the same object.

3.5 Program and linkage [basic.link]

9 Two names that are the same (Clause 3) and that are declared in different scopes shall denote the same variable, function, type, enumerator, template or namespace if

• both names have external linkage or else both names have internal linkage and are declared in the same translation unit; and
• both names refer to members of the same namespace or to members, not by inheritance, of the same class; and
• when both names denote functions, the parameter-type-lists of the functions (8.3.5) are identical; and
• when both names denote function templates, the signatures (14.5.6.1) are the same.

Both names have external linkage. Both names refer to a member in the global namespace. Neither name denotes a function or a function template. Therefore, both names refer to the same object. Suggesting that the fact that you've got separate declarations invalidates such basic facts is like saying that int i = 0; int &j = i; j = 1; return i; might return zero, because the compiler might have forgotten what j refers to. Of course that must return 1. This has to work, plain and simple. If it doesn't, you've found a compiler bug.

Answer 2

This behavior seems to be correct if you dig a bit into the standard.

First hint is in the note on at section 3.3.1/4, which says:

Local extern declarations (3.5) may introduce a name into the declarative region where the declaration appears and also introduce a (possibly not visible) name into an enclosing namespace;

Which is a little bit vague and seems to imply that compiler is not required to introduce the name upper_bound in the global context when passing through the bar() function, and therefore, when upper_bound appears in the foo() function, there is no connection made between those two extern variables, and therefore, bar() has no side-effect as far as the compiler knows, and thus, the optimization turns into an infinite loop (unless upper_bound is zero to begin with).

But this vague language is not enough, and it is only a cautionary note, not a formal requirement.

Fortunately, there is a precision later on, at section 3.5/7, which goes as follows:

When a block scope declaration of an entity with linkage is not found to refer to some other declaration, then that entity is a member of the innermost enclosing namespace. However such a declaration does not introduce the member name in its namespace scope.

And they even provide an example:

namespace X {
  void p() {
    q();              // error: q not yet declared
    extern void q();  // q is a member of namespace X
  }

  void middle() {
    q();              // error: q not yet declared
  }
}

which is directly applicable to the example you gave.

So, the core of the issue is that the compiler is required not to make the association between the first upper_bound declaration (in bar) and the second one (in foo).

So, let's examine the implication for optimization of the two upper_bound declarations are assumed to be un-connected. The compiler understands the code like this:

void bar() 
{
   extern int upper_bound_1;
   upper_bound_1--;
}

void foo()
{
   extern int upper_bound_2;
   for (int i = 0; i < upper_bound_2; ) {
      bar();
   }
}

Which becomes as follows, due to function inlining of bar:

void foo()
{
   extern int upper_bound_1;
   extern int upper_bound_2;
   while( 0 < upper_bound_2 ) {
      upper_bound_1--;
   }
}

Which is clearly an infinite loop (as far the compiler knows), and even if upper_bound was declared volatile, it would just have an undefined termination point (whenever upper_bound happens to externally be set to 0 or less). And decrementing a variable (upper_bound_1) an infinite (or indefinite) amount of times has undefined behavior, because of overflow. Therefore, the compiler can choose to do nothing, which is an allowed behavior when it's undefined behavior, obviously. And so, the code becomes:

void foo()
{
   extern int upper_bound_2;
   while( 0 < upper_bound_2 ) { };
}

Which is exactly what you see in the assembly listing for the function that GCC 4.8.2 produces (with -O3):

    .globl  _Z3foov
    .type   _Z3foov, @function
_Z3foov:
.LFB1:
   .cfi_startproc
    movl    upper_bound(%rip), %eax
    testl   %eax, %eax
    jle .L6
.L5:
    jmp .L5
    .p2align 4,,10
    .p2align 3
.L6:
    rep ret
    .cfi_endproc
.LFE1:
    .size   _Z3foov, .-_Z3foov

Which can be fixed by adding a global-scope declaration of the extern variable, as such:

extern int upper_bound;

void bar() 
{
   extern int upper_bound;
   upper_bound--;
}

void foo()
{
   extern int upper_bound;
   for (int i = 0; i < upper_bound; ) {
      bar();
   }
}

Which produces this assembly:

_Z3foov:
.LFB1:
    .cfi_startproc
    movl    upper_bound(%rip), %eax
    testl   %eax, %eax
    jle .L2
    movl    $0, upper_bound(%rip)
.L2:
    rep ret
    .cfi_endproc
.LFE1:
    .size   _Z3foov, .-_Z3foov

Which is the intended behavior, i.e., the observable behavior of foo() is equivalent to:

void foo()
{
   extern int upper_bound;
   upper_bound = 0;
}