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 6C4233858D37; Thu,  6 Jul 2023 11:17:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6C4233858D37
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1688642248;
	bh=hUWEDtgDnq98bsznA7aNLr47sKqG6srnND8ljf5+K84=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=A/1UxVPQ8K79BVEtjDFvJyTAA7xzTCleNPUHCI1c+XWcBahayumEmlfktZy4LbRkv
	 MY0LKn0nKqT/xZTxOXmlbEoT3g/Gc7jgLPCJGu/n4NLiNA52FBiLvYVxhLJPbsp6mx
	 7M8JHNeQxOq1QmbeHvBtg01yUWf+LI3TqJAMWNZ4=
From: "npiggin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106895] powerpc64 unable to specify even/odd register
 pairs in extended inline asm
Date: Thu, 06 Jul 2023 11:17:26 +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.0
X-Bugzilla-Keywords: inline-asm
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: npiggin at gmail dot com
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-106895-4-usJkj6E4tf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106895-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106895-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=3D106895

--- Comment #9 from Nicholas Piggin <npiggin at gmail dot com> ---
(In reply to Segher Boessenkool from comment #8)
> (In reply to Peter Bergner from comment #6)
> > (In reply to Segher Boessenkool from comment #5)
> > > Constraints are completely the wrong tool for this.  Just use modes, =
which
> > > *are* the right tool?
> >=20
> > Well you cannot specify modes in the asm, so I think you're saying we n=
eed
> > use the correct type that maps to a internal to GCC mode that has the
> > even/odd register behavior, so something like:
> >=20
> >   unsigned int foo __attribute__ ((mode (XX)));
> >=20
> > ...where XXmode is the new integer mode that gives us even/odd register
> > pairs?  Of course we have to be careful about how this all works wrt -m=
32
> > versus -m64.
>=20
> No, the type there is "unsigned int".  I meant to say exactly what I did =
say:
> just use modes.  Which you indeed do in user code by the mode attribute, =
yes.
>=20
> And you do not need a new mode: PTImode should just work.  But the user
> specifying that is currently broken it seems?

I don't know why constraint is wrong and mode is right or why TI doesn't wo=
rk
but PTI apparently would, but I'll take anything that works. Could we get P=
TI
implemented? Does it need a new issue opened?

>=20
> Without -mpowerpc64 you cannot *have* 128-bit integers in registers.  That
> should be
> fixed, but you cannot have it in just *two* registers, which is what is
> required
> here.  For most targets that then means -m64 is required.=