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 B45D53858C2D; Fri,  3 Feb 2023 21:08:22 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B45D53858C2D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1675458502;
	bh=cMYuwGdvqPMx7f6+c5hU7inoHdiBS5k4KBdVAkZHlI4=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=KWo1aaELvL2a4r2ir6aTeOHVAfB/2OjlfkvZf9VuHj/bL5NdLJSatvOeSMYhQKYbG
	 lB3HxzJCDXOCxi+d4jKjEhS3zBS33S45a9zhcSbJGDGXXNf+lQl0/7d56AKsPosH/p
	 QJ5c0mCVZnjPxl9Sg09XVn4nWM19FOemYcMZiJ6g=
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64
 and x64
Date: Fri, 03 Feb 2023 21:08:22 +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: 12.2.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: 
Message-ID: <bug-108659-4-5MLkExEco4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108659-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108659-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Wilco from comment #5)
> To me a far worse issue is that this difference for 128-bit atomics means
> that LLVM and GCC are binary incompatible. AFAIK isn't an option to make
> them compatible either (on AArch64 GCC13 will use a compatible sequence o=
nly
> if LSE2 is available).

Right and that would mean LLVM is broken for valid C code. And breaks the
binary compatibility with GCC rather than the other way around.
This is not the first time LLVM has chosen to break things with respect to
binary compatibility with GCC (x86_64 argument passing for an example).=