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.
