From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A722B3858C2B; Mon, 8 May 2023 22:09:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A722B3858C2B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683583756; bh=8XsWIkhsBJ9UG4W9L2yARzN5WqhHpswannG4hUtBHRQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UQICr3cvnG3eW6KESgtmZWwzwesjIIqGowtSN4meZo5LvcYarlAfXQ7pUcQaanUSs myFZkWXF5L0+eFh2t6ny+PKxKDTgsbXNNB9JPsqgXxIJcEyRDgqFuQvhwrZuwJ1irT yMFMCWGRhdvl8yM4QnJYO/aFXBWgim7UawbUiJo8= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109778] [13/14 Regression] Wrong code at -O1 and above on x86_64-linux-gnu Date: Mon, 08 May 2023 22:09:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D109778 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aldyh at gcc dot gnu.org, | |amacleod at redhat dot com --- Comment #3 from Jakub Jelinek --- Looking at the #c1 -O3 differences, before that the ranger is able to handle all ranges nicely, as f is being called with [90, 91], which results in [18= 1, 183] before the rotate (which previously wasn't used, but 2 shifts + or), a= nd because the values in that range are 0xb5, 0xb6 and 0xb7 and that rotated b= y 4 is 0x5b, 0x6b, 0x7b we made [0x5b, 0x7b] range out of that (i.e. [91, 123])= and that minus 86 is [5, 37]. Now, with the above mentioned commit, we instead have r>>=3D 4 in the code, apparently that is something range-op.cc doesn't handle (but could, worst case with pretending it is 2 shifts plus or). So that is one thing that should be do= ne. The other is a bug in the wi::[lr]rotate implementation, tree-ssa-ccp.cc is= the only caller of those which passes non-zero width and that is what isn't han= dled correctly. --- gcc/wide-int.h.jj 2023-04-18 11:00:39.926725744 +0200 +++ gcc/wide-int.h 2023-05-08 23:36:41.104412818 +0200 @@ -3187,9 +3187,11 @@ wi::lrotate (const T1 &x, const T2 &y, u width =3D precision; WI_UNARY_RESULT (T2) ymod =3D umod_trunc (y, width); WI_UNARY_RESULT (T1) left =3D wi::lshift (x, ymod); - WI_UNARY_RESULT (T1) right =3D wi::lrshift (x, wi::sub (width, ymod)); + WI_UNARY_RESULT (T1) right + =3D wi::lrshift (width !=3D precision ? wi::zext (x, width) : x, + wi::sub (width, ymod)); if (width !=3D precision) - return wi::zext (left, width) | wi::zext (right, width); + return wi::zext (left, width) | right; return left | right; } @@ -3204,10 +3206,11 @@ wi::rrotate (const T1 &x, const T2 &y, u if (width =3D=3D 0) width =3D precision; WI_UNARY_RESULT (T2) ymod =3D umod_trunc (y, width); - WI_UNARY_RESULT (T1) right =3D wi::lrshift (x, ymod); + WI_UNARY_RESULT (T1) right + =3D wi::lrshift (width !=3D precision ? wi::zext (x, width) : x, ymod); WI_UNARY_RESULT (T1) left =3D wi::lshift (x, wi::sub (width, ymod)); if (width !=3D precision) - return wi::zext (left, width) | wi::zext (right, width); + return wi::zext (left, width) | right; return left | right; } fixes it but I wonder if we shouldn't return if (width !=3D precision) wi::= sext (left | right, width); instead or do that depending on is_sign_extended, or= do the extension in the caller (tree-ssa-ccp.cc).=