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 DA7C83858D32; Mon, 27 Feb 2023 11:02:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DA7C83858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677495748;
	bh=DtOJoDPUDE00hu6hWUU7UPKAcVPEJtwIp7QKQW/df74=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=fANmkYSX+JOhhFkYJnVw1UJREkGFTgB7XYBIGx6m8vdymkE4DRIaCKJ62+hxH5iwd
	 LOT5RltBA8WmX0lfEGdFD6iR7Je4THOKoVquuJwxI4LwcGWV5iLxmR7yKJ8D3ZPPAH
	 YFYRess/A+TdhxWNWFcmcRROPeldbXKS8TYMBjGA=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/108941] Error: operand type mismatch for `shr' with binutils
 master
Date: Mon, 27 Feb 2023 11:02:28 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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-108941-4-tbdWmrq0d9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108941-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108941-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=3D108941

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to jbeulich from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > GCC doesn't even have that information at all, at the RTL level it does=
n't
> > know
> > if it was signed or unsigned.
> > All it has is the constraint and operand for it, like (reg:QI 126) or
> > (const_int -1).
> > As I said earlier, constants are always sign-extended from their mode.
> > One could e.g. have during expansion (set (reg:QI 126) (const_int -1))
> > and later on asm_operands with "ic" and (reg:QI 126).  Same assignment =
for
> > int8_t x =3D -1 or int8_t x =3D 255 or uint8_t x =3D -1 or uint8_t x =
=3D 255, at
> > GIMPLE one can differentiate that based on types, at RTL one has just m=
ode.
>=20
> While for int8_t x =3D -1 or int8_t x =3D 255 I can see that the result i=
s as
> described, for uint8_t x =3D -1 or uint8_t x =3D 255 (or, as in the examp=
le, a
> constant the was cast to an unsigned 8-bit type) why is it not (const int
> 255)?

Because RTL doesn't have the notion of signed/unsigned types, only modes (w=
hich
don't have a sign).  For many operations there is no difference in how they
behave with signed and unsigned values, say PLUS works the same.  And where=
 it
matters, the signed vs. unsigned is encoded in the code of the operation (t=
here
is say arithmetic right shift and logical right shift).  (const_int 255) is
invalid where 8-bit quantity is required.=