Benefit of endless-loops without side effects in C++ being undefined behavior compared to C?

Question

In C++ loops as

for(;;) {}

are undefined behavior, whereas they are not in C(?).

On P2809R0. Trivial infinite loops are not Undefined Behavior, it is expressed that there are good reasons for doing so. Are there any simple examples to make that clear?

Answer 1

The reasons are optimizations only.

If the compiler can assume that all loops without side effects terminate, it does not have to prove that.

If the non-terminating loops were allowed, the compiler would be allowed to perform certain optimizations only if it could prove termination, that is impossible in general so it would turn into pattern recognition game. And for what benefit?

The underlying issue is that non-termination is a kind of side effect on itself. Any observable effect which is certain to happen after the loop terminates is observed if and only if the loop terminates, even though the loop doesn't have any effects.

Of course exactly the same reasoning can be done for if(expr) return;. The compiler is not allowed to move stuff after the if before if unless it can prove expr is false. But if is the fundamental control flow mechanism while non-terminating loops are not (IMHO).

Take the following code.

int collatz_conjecture(int i){
    while(i!=1){
        if ((i%2)==0)
            i/=2;
        else
            i=i*3+1;
    }
    return i;
}

int main(){
    collatz_conjecture(10);

    return 5;
}

With -O3, gcc compiles it to:

collatz_conjecture(int):
        mov     eax, 1
        ret
main:
        mov     eax, 5
        ret

So, did the compiler prove the Collatz conjecture in order to determine that it should return 1 for all numbers? Of course not, that is just one of the optimizations allowed by termination assumption (and where UB can happen). The only way the loop can terminate is if i==1 therefore it can assume i==1 after the loop and use it for further optimizations -> the function always return 1 and can thus be reduced to it.

More useful example can be interleaved copy. If you have

loop A
loop B

the compiler is allowed to interleave them even without knowing that A terminates. Many vectorization operations rely on this assumption.

Similarly, reordering of some independent after-loop operations before the loop assumes the loop will terminate.

Answer 2

The primary benefit is simplicity of specification. The as-if rule cannot really accommodate the notion that a program can have behavior which is defined and yet may be observably inconsistent with sequential program execution. Further, the authors of the C and C++ Standards use the phrase "Undefined Behavior" as a catch-all for situations where they didn't think it necessary to exercise jurisdiction, in many cases because they expected that compiler writers would be better placed than the Committee to understand their customers' needs.

Most of the useful optimizations which are facilitated by specifying that if no individual action within a loop would be sequenced relative to some later piece of code, execution of the loop as a whole need not be treated as sequenced either. This is a bit "hand-wavy" with regard to what code comes "after" an endless loop, but it makes clear what it would allow a compiler to do. Among other things, if no individual action within a loop would be sequenced before program termination, then execution of the loop as a whole may be omitted entirely.

An important principle that such a rule would embody, which is missing from the present rule, is that a transform that would introduce a dependency between code within a loop and code outside the loop would also introduce a sequencing relationship. If a loop would exit if a certain condition is true, and code after the loop checks that condition, a compiler may use the result from the earlier check to avoid having to repeat the test, but that would mean that code after the loop was relying upon a value computed within the loop.

A concrete example which illustrates the useful and reckless ways the rule can be applied is shown below:

char arr[65537];
unsigned test(unsigned x, unsigned y)
{
    unsigned i=1;
    while((i & y) != x)
        i*=17;
    return i;
}
void test2(unsigned x)
{
    test(x, 65535);
    if (x < 65536)
        arr[x] = 2;
}

There are two individually-useful optimizations that a compiler could apply when in-lining test into test2:

1. A compiler could recognize that a test to see whether x == (i & 65535) could only report "true" in cases where x is less than 65536, rendering the if test that in test2() redundant.

2. A compiler could recognize that because the only effect of the loop is to compute i, and the value of i will end up being ignored when test() is invoked from within test2(), the code for the loop is redundant.

Eliminating the loop while keeping the isolated if would likely be better than doing the reverse, but the ability of code to uphold what's likely a fundamental requirement--that it not write arr past element 65535--is reliant upon either the loop or the if test being retained. Either would be redundant in the presence of the other, but the absence of either would make the other essential.

Note that giving compilers the freedom to resequence code while keeping data dependencies would not preclude the possibility that a correct application might get stuck in an endless loop when fed some possible inputs, if the need to terminate the application using outside means in some cases would be acceptable. Allowing them to resequence code without regard for the resulting data dependencies, however, will have the ironic effect of speeding up primarily "erroneous" programs that cannot be relied upon to satisfy application requirements, and offer no benefit to most programs that add extra checking or dummy side effects (which would not otherwise be needed to satisfy application requirements) to guard against endless loops.

PS--as a further example of the general concept of two pieces of code being individually redundant in the presence of the other, consider the following functions:

double x,y,z;
void f1(void) {
  x=sin(z);
}
void f2(void)
{
  f1();
  y=sin(z);
  x=0;
}

The assignment x=sin(z); is redundant in the code as written, and could be optimized out, since nothing uses the value stored into x. The computation of sin(z) within f2 is redundant in the code as written, and could be replaced with y=x; since x will already hold the value that needs to be stored into y. It should be obvious, however, that the fact that either transformation could be legitimately applied by itself does not imply that both may be legitimately applied together. The idea that this principle should apply to the kinds of optimization used in the first example snippet would probably have been obvious to the people who wrote the Standard, but unfortunately not to the people who wrote clang and gcc.

Answer 3

In both C and C++, endless loops without side effects exhibit undefined behavior. However, there might be slight differences in how compilers handle this situation between the two languages. Ultimately, relying on undefined behavior in either language is not recommended, as it can lead to unpredictable outcomes. It's best to avoid writing code that intentionally relies on undefined behavior.