From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 85F55389700C; Thu, 22 Oct 2020 08:00:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 85F55389700C From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/97505] [11 Regression] ICE in extract_range_basic, at vr-values.c:1439 since r11-4130-g16e4f1ad44e3c00b8b73c9e4ade3d236ea7044a8 Date: Thu, 22 Oct 2020 08:00:57 +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: 11.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 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 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: Thu, 22 Oct 2020 08:00:57 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97505 --- Comment #4 from Aldy Hernandez --- Looking at vr_values::extract_range_builtin(), I see that every single place where we use ask for a range, we bail on non-integers (symbolics, etc). Th= at is, with the exception of the UBSAN builtins. The UBSAN builtins degrade into PLUS/MINUS/MULT and call extract_range_from_binary_expr, which as I've shown, can special case some symbolics which the ranger doesn't currently handle. Since this is a UBSAN issue, we could still go with the original plan of removing the duplicity in ranger vs vr-values, but we'd still have to leave= in the UBSAN builtin handling, perhaps as vr_values::extract_ubsan_builtin().= =20 This isn't ideal, as we'd like to remove all the common code, but I'd be willing to put up with UBSAN duplication for the time being. A possible solution for this PR would be to disable the assert on the UBSAN builtins: diff --git a/gcc/vr-values.c b/gcc/vr-values.c index 67c88006f13..3021f619319 100644 --- a/gcc/vr-values.c +++ b/gcc/vr-values.c @@ -1432,14 +1432,17 @@ vr_values::extract_range_basic (value_range_equiv *= vr, gimple *stmt) if (is_gimple_call (stmt) && extract_range_builtin (vr, stmt)) { + combined_fn cfn =3D gimple_call_combined_fn (stmt); + if (cfn =3D=3D CFN_UBSAN_CHECK_ADD + || cfn =3D=3D CFN_UBSAN_CHECK_SUB + || cfn =3D=3D CFN_UBSAN_CHECK_MUL) + return; + value_range_equiv tmp; And then, as a follow-up, remove all the builtin code from extract_range_builtin, with the exception of the UBSAN stuff (renaming it to extract_ubsan_builtin). Now... the question is, whether this is worth it, since the plan for next stage1 is to overhaul evrp and vrp, causing vr_values and friends to be entirely removed. If we leave the duplicate code in, we'll have to remembe= r to update the vr_values and ranger versions of this code in sync for the next year. I'm guessing this code doesn't change much?? If we do decide to remove it starting with the proposed patch above, we'd h= ave to do more extensive testing to make sure shit doesn't break. Perhaps test= ing on {-m32,-m64,-fsanitize=3Dsigned-integer-overflow} on x86, ppc64, and poss= ibly other slowpokes such as aarch64. I'm torn. It may be a lot of testing and possible breakage in return for removing 90% of code that will hopefully be entirely removed during the next cycle. Thoughts?=