<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/60419>60419</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Invalid assembly generated with infinite loop
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          sagittarius-a
      </td>
    </tr>
</table>

<pre>
    ## Minimal test-case

```c
#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.

```s
$ 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.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJyMVl9voz4W_TTOy1WRMZCEhzy0yUSqNJ2uutXOY2TwJXjG2Mg2TbuffmWH_M_s_JDVBnzu9fHx4V64c3KrERekeCLFasIH3xq7cHwrvedWDu6BTyojvhaEZYRl8CK17LgCj84_1NwhoStCH8e_U7of9XjPMqlrNQgEki2dF9IkLcm-XcSwTGAjNcLqdfPz8fkd6J2Jx-X78-sPSM8jpfaw3ShT_waSrQ7hJHs6B30YKWCz4d5bWQ0eNxvC5oTNtZFaSY2ElYSVsDP2N9o4VQKZjSkAGmMhPM2ewjifOyAA-sG7GMkOWVjImj2dIH-lGUC7VioMqx3QLB0D9ru_ogZAZqs_c3msvTT6hssxBiz6weoTj8tkUTdhtK-5Uh2elDlbYhXyzzwECATMuNY1sXBQHZf6Vt5z2c9I7qkBvUPu4LDz_O8tQjVswdT1YB3sWtQwOKm3wPUXmN7LTv6XBzlA4QcqELJp0KL24FuugUxpSJlc2TLY_dm5AUGgq63so6AXmDB-GI8kG29AenCInQM_kqq5hgrBYm-NGGoUQNgjdyBdgBsNn_MpGK2-Evi3l0oRtgTuHHaV-oItarTcowjAx7cXkA6k_uBKiuRagTtBwb2BB5nSUekphWbQ0RogDDrQxsPhHQ1QZUwPOy59kO8Q31vTow1p9tYMaT64GjCS1SKCuHOmlnHd2ghM4MVYNB_heJegDWAvldkOGPZwS_HA6mJbjxpM5dB-8EohOCnwAZsGax9y-Jb7GCq183aI0Q4ao5TZBfLnWWEnlQrHMOjaaCHDM67UF-An1oPHSzWPJnOHc87BVL_E0PXwIF5Aao8KCFv7ridsXQ3bEVc8JUlCitGr9OxK0ykNNXA8huxbcMzxrQ2zJIs_AaCg0A-uBQDLPy9A6QmUz2EuIBNQ1kARKA0DABRysEIStiTFk5U9YU_0E8uaFKsxEoKvGaV54LN5ft2Euqw3g0MRwfmxQI-rzk-r4hzqDBqEpgnjeMUKAJDSLO4yloic9spf5xKnXLSBtAmstenD_ern69sK_vX-BoE5_zzqeE_NWVznrD6dKxqm7ymV3ygVNL4VK78Vq_qDWNXVBmezM7FKqPI7Yv3q4n7_KtasvhYrP3A_Xn_SLnCj_1fBeVw8luUbN87_iRvn6YUvBB_3ec8XN-6_977cre1rY4GLwxsLtdEeP30oKc8gpKtDgUFxrLY7u69cHLpBeelbi1ygAN73StaxByTw3oYyGhrFVwxcxoIF0jtUDXT8d6yL4FA7vNcUvn__zwucP18ONnQT9TW2nQhorOlghZXkOn4thQmLvXHSGyvRJfB26gkH_vv4pel6qdACfvbKWLTJRCwyUWYln-Ainc6KdFakNJ20i0JkeZHV85SXs0qUTTXN5iUty1nOUKSsmMgFoyyjaZamOStomuRFSmmeCzpnRVXWFckpdlyqRKmPLjF2O5Gh6S2mNE_LieIVKhc_DxnTuIM4GVp9sZrYRYh5qIZtcLCSzrtTFi-9wsXzvlvd60476VuQupFa-n3jmQxWLVrvexcb6pqw9Vb6dqiS2nSErUPu8d9Db80vrD1h68jIEbaOjP8XAAD___aME3A">