From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 287733858C52; Tue, 28 Feb 2023 07:59:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 287733858C52 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677571187; bh=Xinb5+onObAlDjrT9YaBLB0ysHsMuyllSzDDsyWNZ2s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=s2N5F99yqsmCvND9fbO/thTKOfQemhPgq8NmShUx3HQIdISH4BY/9grMdO8iAUinO 7RaEXxbL0PVcsth/qSmlCfhHmsWkXrUHqpOC2QWwqqdc4xn/wwj3V+ZGMJE9CD7Ah1 v2o4KnD8CE+Hckk+FT511BdHW7FAGsTJWdaafAwA= From: "jbeulich at suse dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/108941] Error: operand type mismatch for `shr' with binutils master Date: Tue, 28 Feb 2023 07:59:46 +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: jbeulich at suse dot com 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108941 --- Comment #16 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #15) > Above you're mixing a 32-bit argument with 8-bit argument in an instructi= on > which > expects probably 2 32-bit arguments or at least both arguments with the s= ame > width. > Just try to pass 2 variables to it and use "ri" and you'll see assembler > errors, > add %dl, %eax and the like. Of course, and I did say the example was over-simplified. If it helps, cons= ider (as also indicated) invoking a macro instead, which then inspects the opera= nds and decides what insn to produce. This could be particularly interesting wi= th the .insn that I'm in the process of preparing to add to x86 gas, where one would then inspect arguments in order to select a suitable major opcode. Si= nce x86 has different possible encodings for "add immediate", the wrongly represented value would then lead to silent bad code generation. And btw - = what "size" to assign to e.g. a sign-extended 8-bit immediate is at least ambigu= ous. I can only repeat: Unless the anomaly is properly called out in non-internal documentation, I continue to think there's a bug here. And the reference to Clang getting it right, which you simply put off, isn't entirely meaningless imo (I agree we're talking about a GNU extension here, but that doesn't imp= ly only GNU tools can get it right).=