[Bug lto/65012] [5 Regression] systemd fails to build at least on ppc64el, powerpc, arm-inux-gnueabihf and aarch64 with -flto (ICE)

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

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, I've managed to reproduce some crash on aarch64, but whether it is the same
one you saw is unclear.
In any case, the backtrace is:
(gdb) p lto_file_data
$3 = (lto_file_decl_data *) 0x0
(gdb) bt
#0  lto_get_decl_name_mapping (decl_data=decl_data@entry=0x0,
name=0x3ffaf719e00 "__PRETTY_FUNCTION__.9700") at
../../gcc/lto-section-in.c:369
#1  0x0000000000ad3f90 in varpool_node::get_constructor (this=0x3ffaf8ea800) at
../../gcc/varpool.c:315
#2  0x0000000000acca64 in get_variable_section (decl=decl@entry=0x3ffaf6c1e60,
prefer_noswitch_p=prefer_noswitch_p@entry=true)
    at ../../gcc/varasm.c:1143
#3  0x0000000000acd8f0 in get_block_for_decl (decl=decl@entry=0x3ffaf6c1e60) at
../../gcc/varasm.c:1216
#4  0x0000000000acf168 in make_decl_rtl (decl=decl@entry=0x3ffaf6c1e60) at
../../gcc/varasm.c:1471
#5  0x0000000000acf788 in make_decl_rtl_for_debug
(decl=decl@entry=0x3ffaf6c1e60) at ../../gcc/varasm.c:1519
#6  0x0000000000625b5c in rtl_for_decl_location (decl=decl@entry=0x3ffaf6c1e60)
at ../../gcc/dwarf2out.c:15950
#7  0x000000000064b518 in loc_list_from_tree (loc=loc@entry=0x3ffaf6c1e60,
want_address=2, context=context@entry=0x0)
    at ../../gcc/dwarf2out.c:14579
#8  0x000000000064e450 in add_location_or_const_value_attribute(dw_die_ref,
tree, bool, enum dwarf_attribute) (die=0x3ffaf9b69f0, 
    decl=0x3ffaf6c1e60, cache_p=cache_p@entry=false, attr=DW_AT_location) at
../../gcc/dwarf2out.c:16083
#9  0x00000000006562a0 in dwarf2out_finish (filename=0x109d2d0 <targetm>
"(\362", <incomplete sequence \361>) at ../../gcc/dwarf2out.c:24554
#10 0x00000000008c7968 in compile_file () at ../../gcc/toplev.c:650
#11 0x0000000000564ee8 in do_compile () at ../../gcc/toplev.c:2066
#12 toplev::main (this=0x0, this@entry=0x3fffffff080, argc=-1295660700,
argc@entry=52, argv=
    0xd80101 <std::__cxx11::messages<char>::do_get(int, int, int,
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&) const+17>, argv@entry=0x3fffffff1b8) at ../../gcc/toplev.c:2164
#13 0x00000000005657f4 in main (argc=52, argv=0x3fffffff1b8) at
../../gcc/main.c:39

I.e. dwarf2out trying to compute RTL for a __PRETTY_FUNCTION__ VAR_DECL, but
has NULL lto_file_data.  The VAR_DECL is streamed in from LTO,
but without corresponding varpool node.  That node is added only during the
make_decl_rtl_for_debug call, so obviously it has NULL lto_file_data member and
varpool_node::get_constructor ICEs on it,
because it assumes it must be non-NULL.

So, either we change varpool_node::get_constructor, so that it treats
!lto_file_data the same as !in_lto_p.
Or tweak make_decl_rtl_for_debug to temporarily clear in_lto_p flag and restore
afterwards.
Or add another global flag which would tell us that we are called from
make_decl_rtl_for_debug and be more permissive in that case (i.e. bail out for
NULL lto_file_data).

Honza, your preference?