From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1AE33386483D; Mon, 19 Jul 2021 18:44:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1AE33386483D From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/101496] [12 Regression] ice during GIMPLE pass: evrp Date: Mon, 19 Jul 2021 18:44:04 +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: 12.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on bug_status everconfirmed 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 18:44:04 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101496 Andrew Macleod changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2021-07-19 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #6 from Andrew Macleod --- This test case has unreachable code in it.=20 This issue comes down to func_14_s_5.0_1 =3D func_14_s_5; _2 =3D func_14_s_5.0_1 < 0; c_1.2_4 =3D c_1; _5 =3D func_14_s_5.0_1 !=3D c_1.2_4; _6 =3D _2 | _5; _7 =3D (int) _6; us_3.3_8 =3D us_3; _9 =3D _7 | us_3.3_8; us_3 =3D _9; us_3.6_11 =3D (unsigned int) _9; if (us_3.6_11 =3D=3D 0) goto ; [INV] else goto ; [INV] We determine that in order for us_3.6_11 to be =3D=3D 0 and take the branch= to bb4, that _9, _7, _2 and _5 must all also be 0. This means that _5 =3D func_14_s_5.0_1 !=3D c_1.2_4; must be false, which then means that func_14_s_5.0_1 =3D=3D c_1.2_4 _2 being false also means func_14_s_5.0_1 >=3D 0 or [0, +INF] Next: : _16 =3D c_1.2_4 >=3D _9; _17 =3D (unsigned int) _16; if (_17 !=3D 0) goto ; [INV] else goto ; [INV] to take the branch to bb5, c_1.2_4 must be < _9, (_9 is known to be [0,0].. meaning its range would be [-INF, -1]. we arent fully exploiting equivalences yet, so we dont fold this branch, ev= en though we potentially could. With func_14_s_5.0_1 =3D=3D c_1.2_4, that me= ans c_1.2_4 will enter this branch with the range [0, +INF] which means it can never be < _9 and we will always branch to BB 9. We currently miss that f= old, so don't realize yet that bb_5 in unreachable. but this leads us to the next branch, which is causing the problem: : if (func_14_s_5.0_1 <=3D c_1.2_4) goto ; [INV] else goto ; [INV] Ranger first tries to fold with relations, so it determines that this is al= ways TRUE since func_14_s_5.0_1 =3D=3D c_1.2_4. The simplification code still h= as legacy support in it, and confirms that whatever we come up with the with n= ew range API matches the old code. The old code says=20=20=20 func_14_s_5.0_1 =3D=3D [0, +INF], and c_1.2_4 =3D=3D [-INF, -1], so this = branch is never taken.. result is FALSE. Now an assert it tripped saying the 2 approaches do not agree on which edge would be taken. The code is unreachable.. so it doesnt really matter. To fix this, I am tweaking the simplification code for now to simply use the value the new API returns, if it returns one. Otherwise, it then checks the old API and the only time it is allowed to fi= nd a taken edge is if the NEW API says the fold is undefined.=20 Eventually we can remove that too, but for now, I leave it as a sanity chec= k to ensure we dont find something important, and it is harmless for the OLD API code to remove unreachable code. This function eventually folds to [local count: 10631108]: [local count: 1073741824]: goto ;=