From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 16D983838038; Thu,  6 May 2021 20:53:43 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 16D983838038
From: "liblfds_gccbz at winterflaw dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not
 to work on 7.1.0
Date: Thu, 06 May 2021 20:53:42 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 7.1.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: liblfds_gccbz at winterflaw dot net
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-80878-4-xc4M4x4d2o@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-80878-4@http.gcc.gnu.org/bugzilla/>
References: <bug-80878-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2021 20:53:43 -0000

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

liblfds admin <liblfds_gccbz at winterflaw dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liblfds_gccbz at winterfla=
w 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 =3D 2000;
>=20
> __int128_t g(void)
> {
>   return t;
> }
>=20
> DOES NOT WORK if you use CAS (or ldaxp/stlxp).
>=20
> So clang is broken really ....
>=20
> 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 sleep=
ing.
 Such data structures are used in kernels, at times and in places where
sleeping is absolutely forbidden and will cause the kernel to panic.=20
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 f=
ace
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,=