C `goto` loops are optimized out in LLVM versions ABOVE 12

[gkgoat1]

Resurgence of old bug 965 within C loops made with goto statements. Since they aren't iteration statements, they should not be affected and should not be required to progress. This bug has existed since at least Clang 20, possibly stretching back to Clang 12. This should not cause problems with Rust code, but their team probably should be contacted anyway

this C source reproduces, on latest Clang

This is a miscompilation, but usually comes up in compiler outputs, not hand-written source; Rust, Zig, and modern LLVM languages should not be affected as they never set any progress attributes. (C++ faces this issue only in extern "C" function definitions, which are rarely compiled to)

[gkgoat1]

For now, we are dealing as-if this issue was #60622. That still doesn't change the status of this issue itself, as it uses goto, which is not specified to have any loop-detection properties. We are also using C instead of C++.

[DimitryAndric]

Try using -fno-finite-loops, which lets you get away with undefined behavior:

$ clang++-19 -O1 -S pr149675.cpp -o -
...
_Z2f0v:                                 # @_Z2f0v
        .cfi_startproc
# %bb.0:
.Lfunc_end0:
        .size   _Z2f0v, .Lfunc_end0-_Z2f0v
...

$ clang++-19 -O1 -fno-finite-loops -S pr149675.cpp -o -
_Z2f0v:                                 # @_Z2f0v
        .cfi_startproc
# %bb.0:
        .p2align        4, 0x90
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
        jmp     .LBB0_1
.Lfunc_end0:
        .size   _Z2f0v, .Lfunc_end0-_Z2f0v
...

[gkgoat1]

IIRC it's only UB in C++.

[DimitryAndric]

Looking at http://wg21.link/P2809r3 by @jfbastien you are probably right. JF mentions that "C and C++ diverge in their definition of forward progress guarantees", and "This is unfortunate because using an infinite loop is a common idiom in low-level programming".

That said, maybe for C the optimizer could assume -fno-finite-loops by default... :)

[nikic]

Resurgence of old bug 965 within C loops made with goto statements. Since they aren't iteration statements, they should not be affected and should not be required to progress. This bug has existed since at least Clang 20, possibly stretching back to Clang 12. This should not cause problems with Rust code, but their team probably should be contacted anyway

this C source reproduces, on latest Clang

Can you please provide a proper reproducer, using clang on C code (unlike your godbolt links, which are all C++)?

As far as I can tell, this behaves exactly as expected, with the infinite loop being preserved in C and optimized away in C++: https://c.godbolt.org/z/fG4xqEzhs

[gkgoat1]

Resurgence of old bug 965 within C loops made with goto statements. Since they aren't iteration statements, they should not be affected and should not be required to progress. This bug has existed since at least Clang 20, possibly stretching back to Clang 12. This should not cause problems with Rust code, but their team probably should be contacted anyway
this C source reproduces, on latest Clang

Can you please provide a proper reproducer, using clang on C code (unlike your godbolt links, which are all C++)?

As far as I can tell, this behaves exactly as expected, with the infinite loop being preserved in C and optimized away in C++: https://c.godbolt.org/z/fG4xqEzhs

Just noticed that the godbolt links were c++. I might issue a follow-up PR to w2c2 removing the preventative measure that does nothing. Closing as completed.