[Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-21 14:05:42 UTC ---
On Wed, 21 Dec 2011, markus at trippelsdorf dot de wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
> 
> --- Comment #17 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-21 13:47:16 UTC ---
> It's a little bit faster now. But it still takes 9 CPU-minutes
> to output all ltrans files. And then the following happens:
> 
> At top level:
> lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> make[6]: *** [/tmp/ccQIIdf5.ltrans7.ltrans.o] Error 1
> make[6]: *** Waiting for unfinished jobs....
> lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> make[6]: *** [/tmp/ccQIIdf5.ltrans8.ltrans.o] Error 1
> lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22501
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> make[6]: *** [/tmp/ccQIIdf5.ltrans10.ltrans.o] Error 1
> 
> :-(

*sigh*

> During the 9 minutes the following happens:
> 
> +  27.72%        lto1-wpa  lto1                           [.] htab_expand
> +  12.88%        lto1-wpa  lto1                           [.] lto_read_decls
> +  12.04%        lto1-wpa  lto1                           [.] linemap_lookup
> +   8.31%        lto1-wpa  lto1                           [.]
> htab_find_slot_with_hash 
> +   6.71%        lto1-wpa  lto1                           [.]
> iterative_hash_hashval_t
> +   6.51%        lto1-wpa  lto1                           [.] gimple_type_eq
> +   3.74%        lto1-wpa  lto1                           [.] gimple_type_hash
> +   2.60%        lto1-wpa  libc-2.14.90.so                [.] _int_malloc
> +   2.01%        lto1-wpa  libc-2.14.90.so                [.] memset
> +   1.46%        lto1-wpa  lto1                           [.] gtc_visit
> +   1.23%        lto1-wpa  lto1                           [.]
> lookup_type_pair.isra.108
> +   1.11%        lto1-wpa  libc-2.14.90.so                [.] _int_free
> +   1.04%         swapper  [kernel.kallsyms]              [k] default_idle
> 
> Zoom into htab_expand:
> 
>          :        static inline hashval_t
>          :        htab_mod_m2 (hashval_t hash, htab_t htab)
>          :        {
>          :          const struct prime_ent *p =
> &prime_tab[htab->size_prime_index];
>          :          return 1 + htab_mod_1 (hash, p->prime - 2, p->inv_m2,
> p->shift);
>     0.00 :          b6e9a4:       sub    %eax,%r9d
>     0.00 :          b6e9a7:       jmp    b6e9ba <htab_expand+0x14a>
>     0.00 :          b6e9a9:       nopl   0x0(%rax)
>          :                index -= size;
>          :
>          :              slot = htab->entries + index;
>          :              if (*slot == HTAB_EMPTY_ENTRY)
>          :                return slot;
>          :              else if (*slot == HTAB_DELETED_ENTRY)
>     5.04 :          b6e9b0:       cmp    $0x1,%rax
>     6.16 :          b6e9b4:       je     b6ea8b <htab_expand+0x21b>
>          :            abort ();
>          :
>          :          hash2 = htab_mod_m2 (hash, htab);
>          :          for (;;)
>          :            {
>          :              index += hash2;
>     0.00 :          b6e9ba:       add    %r9d,%edx
>          :              if (index >= size)
>    15.48 :          b6e9bd:       mov    %edx,%eax
>    22.35 :          b6e9bf:       cmp    %rax,%rsi
>     0.00 :          b6e9c2:       ja     b6e9c8 <htab_expand+0x158>
>          :                index -= size;
>     0.63 :          b6e9c4:       sub    %esi,%edx
>    12.78 :          b6e9c6:       mov    %edx,%eax
>          :
>          :              slot = htab->entries + index;
>     0.70 :          b6e9c8:       lea    (%r10,%rax,8),%r8
>          :              if (*slot == HTAB_EMPTY_ENTRY)
>    12.99 :          b6e9cc:       mov    (%r8),%rax
>     0.63 :          b6e9cf:       test   %rax,%rax
>     1.96 :          b6e9d2:       jne    b6e9b0 <htab_expand+0x140>
>          :                  PTR *q = find_empty_slot_for_expand (htab,
> (*htab->hash_f) (x));
>          :
>          :                  *q = x;
>          :                }
>          :
>          :              p++;
>     0.00 :          b6e9d4:       add    $0x8,%r13
>          :
>          :              if (x != HTAB_EMPTY_ENTRY && x != HTAB_DELETED_ENTRY)
>          :                {
>          :                  PTR *q = find_empty_slot_for_expand (htab,
> (*htab->hash_f) (x));
>          :
>          :                  *q = x;
>     9.74 :          b6e9d8:       mov    %r14,(%r8)
>          :                }
>          :
>          :              p++;
>          :

I can imagine this being triggered by the

@@ -845,6 +855,14 @@ uniquify_nodes (struct data_in *data_in,
                    if (ix < i)
                      lto_fixup_types (f2);
                    streamer_tree_cache_insert_at (cache, f1, ix);
+                   /* Make sure that the type of a TYPE_DECL refers
+                      to the type decl that prevails in the prevailing
+                      record or union type.  */
+                   if (TREE_CODE (f1) == TYPE_DECL)
+                     {
+                       tree f1t = GIMPLE_REGISTER_TYPE (TREE_TYPE (f1));
+                       TYPE_NAME (f1t) = f1;
+                     }
                  }
            }

as we are basically re-connecting two SCCs.  So the hash value
of t probably changes when we do the above :/

One of the real issues we have when registering/merging types is
that while we do SCC based comparisons we only register the
entry point into the SCC, so when another entry point to the same
SCC comes from a different instance we end up mixing instances
from different SCCs for the prevailing one (which is exactly what
causes the TYPE_FIELDS chain to become corrupt in this bug).

Maybe I should look into fixing that fundamental issue instead
(I'll still go forward with the speedup patch I think, it's also
a consistency fix).  Likewise the DECL_SOURCE_LOCATION comparison
change is probably necessary in the end.