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 1C79E3858D35; Mon, 27 Feb 2023 10:07:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1C79E3858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677492421;
	bh=Tv9ZZZJ8xpPgVwgrJPTsuOfbvPrpMZwsJSa3DfXGRn8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=eOLmBqGxuPC/CeHnVSSoBzThPHkpEG3QdXjDB+vp8j3PSitw2DhrMdD/vCFyaKd0/
	 vroJJr1ISXyMRBHkS1vBMfbYvsjTFOVXddfiUKe27oHfovhdTO3q2imLaH0rAciUux
	 X2Hj0fCkXmTA9gq8T65IKu9Qa9CxrXRjWzy5Aw8Q=
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 10:07:00 +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-CE5cLaD7XA@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 #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Li=C5=A1ka from comment #2)
> Well, I just noticed clang transforms it into:
> $ clang libavformat.i -w -S -O2 -o /dev/stdout | grep shr
> 	shrl	$255, %eax

Well, GNU inline assembly is a GNU extension, how clang implemented the GNU
extension doesn't change anything on what GCC should and shouldn't do.
That said, if binutils rejects negative immediates and not also too large
immediates,
it is completely wrong.  IMHO it should reject neither, it is a runtime thi=
ng
what will happen.  E.g.
int
foo (int x)
{
  return x >> -1;
}
and similar can appear in dead code just fine, the important thing is not to
trigger
it at runtime.  GCC uses for 32-bit shifts on x86 actually "cI" constraint
rather than "ci" and so negative or too large shift counts will be reloaded
into %cl register and so it itself doesn't care.=