From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E9CA43858431; Mon, 4 Dec 2023 16:02:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9CA43858431 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701705770; bh=TMdSzYYmakTh/amOeVg/MxbUFHdutQJpF744Acshq9g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qYyMrpbjyQYK9BhA/8IFAKWnwYqkdjbH/F519MEm3okv6nCXL81eXLPA9t+UVEBd7 Ajisf+/yLWc1WFexgnlQhdmVtS2aaWHJ8bfgip/wVMyEUBFKfd5jhtNOCJzg3Frg2G r9lWxbeDEn35kRU4zIiA/TkCh9BImhkNjb6Vis/w= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1 Date: Mon, 04 Dec 2023 16:02:49 +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: 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: P3 X-Bugzilla-Assigned-To: jakub 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=3D112843 --- Comment #5 from Andrew Macleod --- (In reply to Richard Biener from comment #3) > (In reply to Richard Biener from comment #2) > > what?! Ick. It definitely shouldn't re-fold anything but only scrap c= aches > > _at most_. >=20 > So it does >=20 > // Only update if it already had a value. > if (m_cache.get_global_range (r, lhs)) > { > // Re-calculate a new value using just cache values. > Value_Range tmp (TREE_TYPE (lhs)); > fold_using_range f; > fur_stmt src (s, &m_cache); > f.fold_stmt (tmp, s, src, lhs); >=20 > // Combine the new value with the old value to check for a change. > if (r.intersect (tmp)) > { > if (dump_file && (dump_flags & TDF_DETAILS)) > { > print_generic_expr (dump_file, lhs, TDF_SLIM); > fprintf (dump_file, " : global value re-evaluated to "); > r.dump (dump_file); > fputc ('\n', dump_file); > } > m_cache.set_global_range (lhs, r); >=20 > WTF? If a pass invalidates a range it needs to properly do this itself. > But update_stmt itself _never_ should alter range info. what do you mean? when a statement is changed, it may generate a different range than it did before, so we re-evaluate the statement to see if the res= ult is different. If it is, then we update it in the cache. All its doing is re-calculating and updating the cache values. It looks to me like the problem is the stmt is being added in a way that le= aves the IL in an illegal state, tree lhs2 =3D make_ssa_name (type); gimple *g =3D gimple_build_assign (lhs, NOP_EXPR, lhs2); if (stmt_ends_bb_p (stmt)) { edge e =3D find_fallthru_edge (gsi_bb (gsi)->succs); gsi_insert_on_edge_immediate (e, g); } else gsi_insert_after (&gsi, g, GSI_SAME_STMT); gimple_set_lhs (stmt, lhs2); (gdb) p print_generic_expr (stderr, lhs, 0) _1$3 =3D void (gdb) p print_generic_expr (stderr, lhs2, 0) _12$4 =3D void (gdb) p print_gimple_stmt (stderr, stmt, 0, 0) _1 =3D x_4(D) * 5; $5 =3D void (gdb) p print_gimple_stmt (stderr, g, 0, 0) _1 =3D (_BitInt(128)) _12; $6 =3D void So we have=20 _1 =3D x_4(D) * 5; then we create=20 _1 =3D (_BitInt(128)) _12; And add it to the IL... and finally change the original stmt to=20 _12 =3D x_4(D) * 5 how is that right? _1 is now a different type? but regardless, we have 2 statements with _1 as a LHS for a brief time. And rangers real complaint is that we have a range for _1, but its being updated by a stmt which is not actually in the IL yet during this update.. = so it is finding no basic block info for an SSA name which is thinks its knows something about already because it WAS in the IL. It also does not seem correct to me that you can take an existing SSA_NAME = and change its type on the fly while its still being used in the IL? Once we create an ssa name, I thought it was immutable from a type point of view un= tl deleted and reused? (gdb) p print_generic_expr (stderr, lhs->typed.type, 0) _BitInt(128)$7 =3D void (gdb) p print_generic_expr (stderr, lhs2->typed.type, 0) int128_t$8 =3D void=