From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DE5BC3858D39; Tue, 28 Feb 2023 07:33:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE5BC3858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677569607; bh=AeNdj3Ag1JB/0Od5fssJvbkx6ClbhVViUdfq4ezaDgY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aGFcorsJdBXIvzMgcIUDFemrtc06zcqqCtixFv8913ORcCog8mQbKf0ttbz/Pro/H 3b8L3SPOmES0mmUAp7g8F6gHt+3iLL11hptWrSxW2rahPT6bU37/XbS391Pl/d+EBm a1X1tGV/TKBz8CV15WKp/2hTyvLoeh53Iiul+w2E= 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:33:25 +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 #14 from jbeulich at suse dot com --- (In reply to Jakub Jelinek from comment #5) > GCC doesn't even have that information at all, at the RTL level it doesn'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). Lack of information at a certain layer doesn't mean this isn't a bug. It me= rely makes whatever possible bug one that's hard to fix. Furthermore you did refer to gcc internal doc as to justifying the behavior. But can you also point me at non-internal doc making explicit that e.g. static inline unsigned aux(unsigned i, unsigned char j) { #if 1 asm("add %1,%0" : "+rm" (i) : "i" (j)); return i; #else return i + j; #endif } unsigned test(unsigned i, unsigned j) { return aux(i, 255) * aux(j, -1); } does not do (at -O1 or -O2) what one would expect (again on x86)? The examp= le is intentionally over-simplified (and hence won't build at -O0); anything m= ore involved could be taken care of by using assembler macros, where it is not overly difficult to separately deal with immediates and registers. In the absence of such documentation I would also view the "has always been like that" argument as at least questionable.=