[Bug lto/52178] New: [4.7 regression] Ada bootstrap failure in LTO mode
ebotcazou at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Feb 8 21:37:00 GMT 2012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
Bug #: 52178
Summary: [4.7 regression] Ada bootstrap failure in LTO mode
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: ebotcazou@gcc.gnu.org
Build: x86_64-*-linux
The problem has been present for months despite the various LTO changes.
The typical error message issued during LTRANS is:
/home/eric/svn/gcc/gcc/ada/lib-load.adb: In function 'lib__load__load_unit':
/home/eric/svn/gcc/gcc/ada/lib-load.adb:344:0: error: type mismatch in
component reference
atree__atree_private_part__node_record___is_extension___XVN
atree__atree_private_part__node_record___is_extension___XVN
# VUSE <.MEM_328>
T142b_492 =
*atree__atree_private_part__nodes__table.19_489[D.105830_491].is_extension___XVN.S0.sloc;
It's a type mismatch between a COMPONENT_REF and the FIELD_DECL (operand #1).
Everything is OK during compilation and the problem is apparently already there
when LTRANS kicks in, so the problem is probably in WPA. As far as I can see,
it merges 2 equivalent types and then updates the cache (uniquify_nodes):
/* If we're going to replace an element which we'd
still visit in the next iterations, we wouldn't
handle it, so do it here. We do have to handle it
even though the field_decl itself will be removed,
as it could refer to e.g. integer_cst which we
wouldn't reach via any other way, hence they
(and their type) would stay uncollected. */
/* ??? We should rather make sure to replace all
references to f2 with f1. That means handling
COMPONENT_REFs and CONSTRUCTOR elements in
lto_fixup_types and special-case the field-decl
operand handling. */
if (ix < i)
lto_fixup_types (f2);
streamer_tree_cache_insert_at (cache, f1, ix);
But, while the types of the old set and the new set of fields are compatible in
GIMPLE, there is at least one field for which the type isn't compatible in the
middle-end sense, and the type verifier chokes.
I'm a little at a loss as to how this is supposed to work: should the type of
the COMPONENT_REF be updated too, i.e is that the ??? above? Should this be
handled via TYPE_CANONICAL, i.e the old and new type must have the same? Or
should this be patched up in input_gimple_stmt, similarly to what is already
done:
/* Fixup FIELD_DECLs in COMPONENT_REFs, they are not handled
by decl merging. */
if (TREE_CODE (op) == ADDR_EXPR)
op = TREE_OPERAND (op, 0);
while (handled_component_p (op))
Any hint is welcome!
More information about the Gcc-bugs
mailing list