[Bug lto/52178] New: [4.7 regression] Ada bootstrap failure in LTO mode

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

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!