From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 4172C3858C27; Mon, 18 Jul 2022 08:26:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4172C3858C27 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072 Date: Mon, 18 Jul 2022 08:26:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: everconfirmed assigned_to bug_status cf_reconfirmed_on 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, 18 Jul 2022 08:26:51 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106334 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot = gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2022-07-18 --- Comment #1 from Richard Biener --- Confirmed. Do we eventually ggc_free during stream-in?! Breakpoint 5, dwarf2out_register_external_die (decl=3D, sym=3D0x42c6e98 "eval.cc.eec30469", off=3D478) at /space/rguenther/src/gcc/gcc/dwarf2out.cc:6072 6072 gcc_checking_assert (!external_die_map->get (decl)); (gdb) p sym $4 =3D 0x42c6e98 "eval.cc.eec30469" (gdb) p off $5 =3D 478 (gdb) c Continuing. Breakpoint 5, dwarf2out_register_external_die (decl=3D, sym=3D0x42c6e98 "eval.cc.eec30469", off=3D455) at /space/rguenther/src/gcc/gcc/dwarf2out.cc:6072 6072 gcc_checking_assert (!external_die_map->get (decl)); (gdb) p sym $6 =3D 0x42c6e98 "eval.cc.eec30469" (gdb) p off $7 =3D 455 so we have the "same" decl (address) but with different decls. Hmm. #0 free_node (node=3D) at /space/rguenther/src/gcc/gcc/tree.cc:1342 #1 0x0000000000b78e43 in unify_scc (data_in=3D0x42b3840, from=3D240, len= =3D4,=20 scc_entry_len=3D1, scc_hash=3D852538354) at /space/rguenther/src/gcc/gcc/lto/lto-common.cc:1769 #2 0x0000000000b79590 in lto_read_decls (decl_data=3D0x7ffff68cdc60,=20 data=3D0x42c66b0, resolutions=3D...) at /space/rguenther/src/gcc/gcc/lto/lto-common.cc:1930 and #0 dwarf2out_register_external_die ( decl=3D,=20 sym=3D0x42c6e98 "eval.cc.eec30469", off=3D478) at /space/rguenther/src/gcc/gcc/dwarf2out.cc:6072 #1 0x00000000010ec851 in lto_input_tree (ib=3D0x7fffffffd770, data_in=3D0x= 42b3840) at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1911 #2 0x00000000010ec141 in lto_read_tree_1 (ib=3D0x7fffffffd770,=20 data_in=3D0x42b3840, expr=3D) at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1706 #3 0x00000000010ec3ef in lto_input_scc (ib=3D0x7fffffffd770, data_in=3D0x4= 2b3840,=20 len=3D0x7fffffffd72c, entry_len=3D0x7fffffffd728, shared_scc=3Dtrue) at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1798 #4 0x0000000000b7945f in lto_read_decls (decl_data=3D0x7ffff68cdc60,=20 data=3D0x42c66b0, resolutions=3D...) at /space/rguenther/src/gcc/gcc/lto/lto-common.cc:1904 note the dwarf2out registering during WPA is just using its hashtable as temporary storage, overwriting an existing entry should be fine there. An alternative would be to delay registering until we know the node is needed or providing a hook to unregister entries when we do free_node. The issue is probably latent everywhere - interesting that it didn't pop up yet. The "cheapest solution" is to short-cut the assert when flag_wpa (it's off with release checking anyway).=