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 7873B3858CDB; Thu, 18 May 2023 15:28:48 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7873B3858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1684423728;
	bh=Z6rRyW7v/whHy2jPY+89z4WTz6SS6gDivlCqh2r+3nY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=bg6pWqcXFyTnFlfW572lBmc6zfqhJ2ykFF3/WKfLnfY3wkqaJFpc5fvnxRg5AEUeI
	 rpvbFtOI1CmYyK4BJHD1vU8tiL6NsCxMPaMSbqHjlB6wbfd2JBv2y7SVbF3ryLy0ua
	 YCmibRSAVWMY2l6zNVDeLmlG8Go+w12uvu1MU7PE=
From: "dimitri.gorokhovik at free dot fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/109903] Register misallocation in hand-crafted asm insn,
 no diagnostics produced
Date: Thu, 18 May 2023 15:28:46 +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: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dimitri.gorokhovik at free dot fr
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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-109903-4-Oy2BwIj8P6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-109903-4@http.gcc.gnu.org/bugzilla/>
References: <bug-109903-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=3D109903

--- Comment #4 from Dimitri Gorokhovik <dimitri.gorokhovik at free dot fr> =
---
Hi Andrew,

I'd agree more with "WONTFIX" here ;-) We are not looking for solution. We =
want
to spare the same hassle to others.

This asm doesn't write to memory, it doesn't even read any -- 'a' is passed
over in the registers with aarch64 and x64_86.

It is also very hard to see the need for early clobber here ... how comes t=
he
version with return value doesn't need it while the other does? The asm
performs regular register loads. Certainly we are not marking all register
loads with early clobbers are we?

WE ended up moving 'a' to output clause, it feels barely more contorted than
the early-clobber method.

> GCC does not look at the inline-asm template except while outputting the =
assembly.
Yep, reason why I let it emit ARMv8 insns for the x64_86 target ;-)=