[Bug c/105495] New: `__atomic_compare_exchange` prevents tail-call optimization

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495

            Bug ID: 105495
           Summary: `__atomic_compare_exchange` prevents tail-call
                    optimization
           Product: gcc
           Version: 11.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Godbolt: https://gcc.godbolt.org/z/7ob6zc17P

Offending testcase:

```c
typedef struct { int b; } cond;

int
__MCF_batch_release_common(cond* p, int c);

int
_MCF_cond_signal_some(cond* p, int x)
  {
    cond c = {x}, n = {2};
    __atomic_compare_exchange(p, &c, &n, 1, 0, 0);
    return __MCF_batch_release_common(p, x);
  }
```


GCC output:

```asm
_MCF_cond_signal_some:
        sub     rsp, 24
        mov     edx, 2
        mov     eax, esi
        mov     DWORD PTR [rsp+12], esi
        lock cmpxchg    DWORD PTR [rdi], edx
        je      .L2
        mov     DWORD PTR [rsp+12], eax      <------- note this extra store,
which clang doesn't generate
.L2:
        call    __MCF_batch_release_common
        add     rsp, 24
        ret
```


Clang output:

```asm
_MCF_cond_signal_some:                  # @_MCF_cond_signal_some
        mov     ecx, 2
        mov     eax, esi
        lock            cmpxchg dword ptr [rdi], ecx
        jmp     __MCF_batch_release_common      # TAILCALL
```

1. If `cond` was defined as a scalar type such as `long`, there is no such
issue.
2. `__atomic_exchange` doesn't suffer from this issue.