[PATCH][?/n] Cleanup LTO type merging

[Richard Guenther]

I've seen us merge different named structs which happen to reside
on the same variant list.  That's bogus, not only because we are
adjusting TYPE_MAIN_VARIANT during incremental type-merging and
fixup, so computing a persistent hash by looking at it looks
fishy as well.

Bootstrapped and tested on x86_64-unknown-linux-gnu.

Richard.

2011-05-16  Richard Guenther  <rguent...@suse.de>

        * gimple.c (gimple_types_compatible_p_1): Use names of the
        type itself, not its main variant.
        (iterative_hash_gimple_type): Likewise.

Index: gcc/gimple.c
===================================================================
*** gcc/gimple.c        (revision 173794)
--- gcc/gimple.c        (working copy)
*************** gimple_types_compatible_p_1 (tree t1, tr
*** 3817,3824 ****
        tree f1, f2;
  
        /* The struct tags shall compare equal.  */
!       if (!compare_type_names_p (TYPE_MAIN_VARIANT (t1),
!                                  TYPE_MAIN_VARIANT (t2), false))
          goto different_types;
  
        /* For aggregate types, all the fields must be the same.  */
--- 3817,3823 ----
        tree f1, f2;
  
        /* The struct tags shall compare equal.  */
!       if (!compare_type_names_p (t1, t2, false))
          goto different_types;
  
        /* For aggregate types, all the fields must be the same.  */
*************** iterative_hash_gimple_type (tree type, h
*** 4193,4199 ****
        unsigned nf;
        tree f;
  
!       v = iterative_hash_name (TYPE_NAME (TYPE_MAIN_VARIANT (type)), v);
  
        for (f = TYPE_FIELDS (type), nf = 0; f; f = TREE_CHAIN (f))
        {
--- 4192,4198 ----
        unsigned nf;
        tree f;
  
!       v = iterative_hash_name (TYPE_NAME (type), v);
  
        for (f = TYPE_FIELDS (type), nf = 0; f; f = TREE_CHAIN (f))
        {