clang >=13.0.0 seems provide invalid optimize for C++, empty while(true) loop and -O1

[yyjdelete]

I notice this when try to convert an do-while loop in my code to an for loop, but forget to remove the while(true);

The code looks like the below, compile it as C++ with -O1 or -O3, it should output aaa for 100 times and do a busy loop forever, but infact, it repeat output aaa forever(looks like an do-while loop outside the for loop)
Tested with clang-18 in Ubuntu 24.04 and godbolt.org

#include <stdio.h>
#include <stdbool.h>
 
int main() {
    for (int i = 0; i < 100; ++i)
    {
        printf("aaa\n");
    }
    while(true);
  return 0;
}

https://godbolt.org/z/r5W1vf6Pc

It works with -O0
It works when compile the code as C code instead of C++
It also works with gcc/g++
According to godbolt.org, it used to works with clang <=12.0.1, and not work for >=13.0.0

[MitalAshok]

Prior to #90066, that infinite loop was undefined behaviour. So in Clang 18 your code can become:

#include <stdio.h>
#include <stdbool.h>
#include <utility>
 
int main() {
    for (int i = 0; i < 100; ++i)
    {
        printf("aaa\n");
    }
    std::unreachable();
  return 0;
}

Which I guess made the optimizer assume that i < 100 must always be false. Doesn't seem like a Clang issue (and in Clang 19, this is well defined because you have a trivial infinite loop, and it does look like this only prints "aaa" 100 times on the main branch.)

[yyjdelete]

Another question, is there any compiler options exists to enable an warn for this undefined behaviour?
I didn't see one with -Wall -Wextra

[frederick-vs-ja]

This is a duplicate of #60622 and should have been fixed by #90066. I belive the old behavior returned in Clang 19.

#60622 is unfortunately locked so I'm hesitant to close this.

It's the standard wording that is somehow obscure, see P2809R3 which clarified that trivial infinite loops are fine. CWG2816 (which hasn't been not resolved yet) is related.

---

I believe the current standard wording is still defective for some non-trivial infinite loops like:

bool b = true; // never a constant expression
while (b) {}

Some people believe this is not UB, but it's totally unclear how is an implementation allowed to perform logic transformation when the assumption in [intro.progress] is violated.

Some people believe this is UB, but it's also unclear (if not impossible) how to formally infer such a conclusion.

[frederick-vs-ja]

Another question, is there any compiler options exists to enable an warn for this undefined behaviour? I didn't see one with -Wall -Wextra

I guess the intent of #9066 is that when the condition is known to be true but not an actual constant expression, Clang should just treat the conditional is simply constant true, so no warning should be emitted as Clang is happy.

But I don't know whether we should warn on the gap between constant true and constant-folded true. CC @cor3ntin.