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 4B5053858CDB; Tue, 28 Feb 2023 08:10:23 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4B5053858CDB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677571823;
	bh=jppCWAALpNl6+vGfbZ+JJUA7Dz6cfoaCM09xENPWmhs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=L+7pZDL9sH88DK6y4UvT5AAsPNtrXzs7M89oZAzknBRVty8CX3hgLxnmX7tGx59Vz
	 uZ4ngOO/5icBmHyAT6j0VRLicvJKLEbrKqh35IAGUnsdvTUED4OD5UADkUho8m8rZC
	 Oi8g5Jq6iPWR5MSHX6PkJN6B8lRvaspNe7JnNPAM=
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: Tue, 28 Feb 2023 08:10:22 +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: 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-108941-4-0HtOsBTr0h@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 #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to jbeulich from comment #16)
> I can only repeat: Unless the anomaly is properly called out in non-inter=
nal
> documentation, I continue to think there's a bug here. And the reference =
to

For inline asm, the only important things besides the exact values are the =
mode
(for integral scalar modes that determines mostly how many bits it has),
constraints
(which determine where it can be passed and limit set of valid values) and
optional
modifiers which change how it is printed.

> Clang getting it right, which you simply put off, isn't entirely meaningl=
ess
> imo (I agree we're talking about a GNU extension here, but that doesn't
> imply only GNU tools can get it right).

Clang definitely doesn't implement the GNU extension correctly, far from it,
because it broke the basic premise that it is a black box for the compiler =
on
which it performs
a text replacement.  It instead parses and assembles the text, so behaves
completely
differently from how the extension was defined.  So it can't be then safely
used for
optimization barriers, one can't use there something not really valid in the
assembler etc.=