[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0

[liblfds_gccbz at winterflaw dot net]

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

liblfds admin <liblfds_gccbz at winterflaw dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liblfds_gccbz at winterflaw dot ne
                   |                            |t

--- Comment #32 from liblfds admin <liblfds_gccbz at winterflaw dot net> ---
(In reply to Andrew Pinski from comment #31)
> Again the problem is stuff like:
> static const _Atomic __int128_t t = 2000;
> 
> __int128_t g(void)
> {
>   return t;
> }
> 
> DOES NOT WORK if you use CAS (or ldaxp/stlxp).
> 
> So clang is broken really ....
> 
> Also GCC for ARM64 emits calls for all compare and exchange because using
> the LSE (from ARMv8.1-a) is useful.

It may be a case of selecting the lesser of two evils.

The problem for me, as an author of a lock-free data structure library, is that
a mutex is not repeat NOT a replacement for a compare-exchange instruction.

This is because lock-free data structures possess the property of not sleeping.
 Such data structures are used in kernels, at times and in places where
sleeping is absolutely forbidden and will cause the kernel to panic. 
Accordingly, replacing an atomic exchange with a mutex does *not* provide
identical functionality - an atomic exchange works fine, a mutex makes the
kernel panic.

To reiterate : I write a library of lock-free data structures, and on the face
of it you would then think I would be a prime user of libatomic, and I
*specifically* MUST avoid libatomic, and indeed have basically implemented my
own, because of how libatomic behaves.

It's crazy that people writing lock-free data structure must specifically
ensure and guarantee they absolutely do not touch libatomic,