[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106334

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
Confirmed.  Do we eventually ggc_free during stream-in?!

Breakpoint 5, dwarf2out_register_external_die (decl=<function_decl
0x7ffff66f0f00 listItems>, sym=0x42c6e98 "eval.cc.eec30469", off=478) at
/space/rguenther/src/gcc/gcc/dwarf2out.cc:6072
6072      gcc_checking_assert (!external_die_map->get (decl));
(gdb) p sym
$4 = 0x42c6e98 "eval.cc.eec30469"
(gdb) p off
$5 = 478
(gdb) c
Continuing.
Breakpoint 5, dwarf2out_register_external_die (decl=<function_decl
0x7ffff66f0f00 operator*>, sym=0x42c6e98 "eval.cc.eec30469", off=455) at
/space/rguenther/src/gcc/gcc/dwarf2out.cc:6072
6072      gcc_checking_assert (!external_die_map->get (decl));
(gdb) p sym
$6 = 0x42c6e98 "eval.cc.eec30469"
(gdb) p off
$7 = 455

so we have the "same" decl (address) but with different decls.  Hmm.

#0  free_node (node=<ggc_freed 0x7ffff66f0f00>)
    at /space/rguenther/src/gcc/gcc/tree.cc:1342
#1  0x0000000000b78e43 in unify_scc (data_in=0x42b3840, from=240, len=4, 
    scc_entry_len=1, scc_hash=852538354)
    at /space/rguenther/src/gcc/gcc/lto/lto-common.cc:1769
#2  0x0000000000b79590 in lto_read_decls (decl_data=0x7ffff68cdc60, 
    data=0x42c66b0, resolutions=...)
    at /space/rguenther/src/gcc/gcc/lto/lto-common.cc:1930

and

#0  dwarf2out_register_external_die (
    decl=<function_decl 0x7ffff66f0f00 listItems>, 
    sym=0x42c6e98 "eval.cc.eec30469", off=478)
    at /space/rguenther/src/gcc/gcc/dwarf2out.cc:6072
#1  0x00000000010ec851 in lto_input_tree (ib=0x7fffffffd770, data_in=0x42b3840)
    at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1911
#2  0x00000000010ec141 in lto_read_tree_1 (ib=0x7fffffffd770, 
    data_in=0x42b3840, expr=<type_decl 0x7ffff66ef7b8 ListIterable>)
    at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1706
#3  0x00000000010ec3ef in lto_input_scc (ib=0x7fffffffd770, data_in=0x42b3840, 
    len=0x7fffffffd72c, entry_len=0x7fffffffd728, shared_scc=true)
    at /space/rguenther/src/gcc/gcc/lto-streamer-in.cc:1798
#4  0x0000000000b7945f in lto_read_decls (decl_data=0x7ffff68cdc60, 
    data=0x42c66b0, resolutions=...)
    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).