https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94237
Bug ID: 94237
Summary: [10 regression] Many (100s) of new LTO fails on Darwin
targets
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This seems to be from "API extension for binutils (type of symbols)."
https://gcc.gnu.org/g:c8429c2aba80f845939ffa6b2cfe8a0be1b50078
Although this might simply be exposing a latent problem.
We are ICE-ing here with a NULL_TREE DECL_UNIT_SIZE.
frame #2: 0x00000001015ad1af cc1`tree_to_uhwi(t=0x0000000000000000) at
tree.c:7361
frame #3: 0x00000001017753d4
cc1`machopic_select_section(decl=0x0000000143422bd0, reloc=0, align=8) at
darwin.c:1591
frame #4: 0x000000010163aec1
cc1`get_variable_section(decl=0x0000000143422bd0,
prefer_noswitch_p=<unavailable>) at varasm.c:1216
frame #5: 0x0000000100efc24a
cc1`::write_symbol_extension_info(t=0x0000000143422bd0) at
lto-streamer-out.c:2793
frame #6: 0x0000000100efcf02
cc1`::produce_symtab_extension(ob=<unavailable>, previous_streamed_symbols=2)
at lto-streamer-out.c:2888
frame #7: 0x0000000100f0f45a cc1`produce_asm_for_decls() at
lto-streamer-out.c:3081
frame #8: 0x0000000101008e34 cc1`::write_lto() at passes.c:2617
frame #9: 0x000000010100b0a2
cc1`::ipa_write_summaries_1(encoder=0x00000001027003e0) at passes.c:2678
frame #10: 0x000000010100c352 cc1`ipa_write_summaries() at passes.c:2733
frame #11: 0x00000001009b4f7e cc1`::ipa_passes() at cgraphunit.c:2667
frame #12: 0x00000001009b55c0
cc1`symbol_table::compile(this=0x0000000144c05100) at cgraphunit.c:2754
frame #13: 0x00000001009b6ab6
cc1`symbol_table::finalize_compilation_unit(this=0x0000000144c05100) at
cgraphunit.c:3001
====
Background.
Darwin's linker makes use of 'atoms' which are non-zero-sized code and data
fragments starting with a linker-visible symbol. These can be rearranged in
the manner of ELF function and data sections but at a finer granularity.
One consequence of this is that two atoms may not share the same address,
therefore no two linker-visible symbols may refer to the same address.
This means that zero-sized objects (with a linker-visible-symbol) must be
padded to at least one byte. If unhandled, this would prevent section anchors
from working since the size of objects 'lies' c.f. that recorded in the decls.
To cater for this, we place zero-sized objects in separate sections and mark
those sections as not supporting section anchors.
===
Therefore, whenever the Darwin backend is asked for the section for a variable,
it checks to see if the variable is zero-sized before placing it.
'machopic_select_section' is failing because the VAR_DECLs are being passed
with DECL_UNIT_SIZE unset (i.e. NULL_TREE) which means that either the type is
incomplete or that it has not been laid out.
Clearly, we can avoid the ICE by acting in some way on the NULL size - but
maybe that means we're streaming incomplete or incorrect information.
====
In the cases I've examined so far, the var decls are arrays that might have
unspecified dimensions ...
int x[];
but also the vtables in typeinfos are failing.
There are many fails, and they have not all be analysed.
