From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D12483858C78; Thu, 8 Feb 2024 14:04:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D12483858C78 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707401085; bh=nrI9b0YywtyjwytzfeolPy0fBk2euhwIEJ6X6mvFpw4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aaxOAEzjWOaS7aH6q4dmM1nW/3hPvg9PFOcPpZMcWrrljXEPmcoSJVZuMuhXlTRZN R0Zj1p9cr8DI3Th83ysxolg4qNvXxpvNuliFElGGJuykYNFHLsSdm/cLgpYK/v5r2J QP51sXpOzbW3O9Iefdko4ZvJ0pqa5djqNftZm3vk= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/113774] wrong code with _BitInt() arithmetics at -O2 Date: Thu, 08 Feb 2024 14:04:44 +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: rguenth 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: --- 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=3D113774 --- Comment #5 from Richard Biener --- This must go wrong during alias disambiguation, somehow figuring we can ign= ore the backedge?! The ref we hoist is _68 =3D VIEW_CONVERT_EXPR(b)[_146]; where _146 is _49 + 1, but _49 is an IV: _134 =3D _105 & 1; MEM [(unsigned _BitInt(257) *)&b + 32B] =3D _134; [local count: 1073741824]: # _49 =3D PHI <0(4), _50(28)> it's also odd that we seem to arrive at b + 32B. Value numbering stmt =3D _146 =3D PHI <_145(8), _140(31)> Setting value number of _146 to _140 (changed) Making available beyond BB10 _146 for value _140 ... Value numbering stmt =3D .MEM_150 =3D PHI <.MEM_149(8), .MEM_139(31)> Setting value number of .MEM_150 to .MEM_150 (changed) Value numbering stmt =3D _68 =3D VIEW_CONVERT_EXPR(b)[_14= 6]; Setting value number of _68 to _134 (changed) huh. Hmm. But we have # RANGE [irange] sizetype [4, 4][6, +INF] MASK 0xfffffffffffffffe VALUE 0= x1 _140 =3D _49 + 1; # RANGE [irange] sizetype [1, 2][4, 4][6, +INF] MASK 0xfffffffffffffffe V= ALUE 0x1=20 # _146 =3D PHI <_145(8), _140(6)> we should look at the range of _146 Hmm, I _think_ I know what happens. We have [local count: 1073741824]: # _49 =3D PHI <0(4), _50(28)> # _55 =3D PHI <0(4), _56(28)> _51 =3D VIEW_CONVERT_EXPR(b)[_49]; if (_49 <=3D 2) goto ; [80.00%] else goto ; [20.00%] [local count: 214748360]: _135 =3D .USUBC (0, _51, _55); _136 =3D IMAGPART_EXPR <_135>; _137 =3D REALPART_EXPR <_135>; _138 =3D _51 | _137; bitint.6[_49] =3D _138; _140 =3D _49 + 1; _141 =3D VIEW_CONVERT_EXPR(b)[_140]; and this is the "same" valueized ref (what gets recorded in the hashtable), but here we can see that _140 >=3D 4 which makes it known 4 based on the array extent. This matches it up with the store of _134: Value numbering stmt =3D _141 =3D VIEW_CONVERT_EXPR(b)[_1= 40]; Setting value number of _141 to _134 (changed) _134 is available for _134 we record the expression with the VUSE of the definition. Later when we look up the same expression from the later block (where _140 isn't known to be 4) we find the very same expression when looking with the VUSE of the definition and thus we take the expression already in the hashtable which has been assigned the value _134 and then boom. Sth like the following is miscompiled at -O2 by FRE. int a[3]; int __attribute__((noipa)) foo(int i, int x) { int tem =3D 0; a[2] =3D x; if (i < 1) ++i; else { ++i; tem =3D a[i]; } tem +=3D a[i]; return tem; } int main() { if (foo (0, 7) !=3D 0) __builtin_abort(); }=