Invalid assembly generated with infinite loop

[sagittarius-a]

Minimal test-case

#include <stdio.h>

#define DO_WAIT 0
#define DO_ACTION 1

int g_lock = DO_WAIT;

void __attribute__((noinline)) worker() {
  for (;;) {

    puts("worker");
    g_lock = DO_WAIT;

    while (g_lock != DO_ACTION) {
    }

    puts("Action");
  }
  return;
}

void dontcallme() { puts("Don't call me"); }

int main() {
  worker();
  return 0;
}

The bug occurs when using any optimization level different than 0.

Issue description

Note: it seems the bug can be reproduced as is on x86 only. Still, assembly generated on ARM is invalid.

The assembly generated for the worker function does not include the loop waiting for the proper g_lock value, and the associated code. Moreover, no epilogue is generated for the function.

An observable side-effect is that the instructions following the function will be unconditionally executed.

$ objdump -dM intel /tmp/bug
[...]
0000000000001160 <worker>:
    1160:       50                      push   rax
    1161:       48 8d 3d 9c 0e 00 00    lea    rdi,[rip+0xe9c]        # 2004 <_IO_stdin_used+0x4>
    1168:       e8 c3 fe ff ff          call   1030 <puts@plt>
    116d:       0f 1f 00                nop    DWORD PTR [rax]

0000000000001170 <dontcallme>:
    1170:       48 8d 3d 94 0e 00 00    lea    rdi,[rip+0xe94]        # 200b <_IO_stdin_used+0xb>
    1177:       e9 b4 fe ff ff          jmp    1030 <puts@plt>
    117c:       0f 1f 40 00             nop    DWORD PTR [rax+0x0]

0000000000001180 <main>:
    1180:       50                      push   rax
    1181:       e8 da ff ff ff          call   1160 <worker>
[...]

For additional context, I discovered the bug writing a multithreaded application. This is why the C code itself makes no sense.

LLVM

Currently using LLVM from Debian testing repositories. Reproduced the bug using Compiler explorer.

[asl]

Infinite loops without side effects are undefined behavior in C/C++: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm

[adah1972]

Infinite loops without side effects are undefined behavior in C/C++: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm

No, it is not in C. And it is debatable in C++. C and C++ have different wordings on this topic, and C explicitly allows empty loops like while (1) or for (;;) (my emphasis: ‘An iteration statement may be assumed by the implementation to terminate if its controlling expression is not a constant expression’), while C++ states in a completely different way and explicitly says the intention is ‘to allow compiler transformations such as removal of empty loops’. No standard explicitly declares infinite loops without side effects as undefined behavior—removal of a empty loops is not equivalent to making it undefined behavior.