public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
@ 2011-12-20 12:06 markus at trippelsdorf dot de
2011-12-20 12:14 ` [Bug lto/51635] " rguenth at gcc dot gnu.org
` (25 more replies)
0 siblings, 26 replies; 27+ messages in thread
From: markus at trippelsdorf dot de @ 2011-12-20 12:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Bug #: 51635
Summary: [4.7 regression] ICE in in dwarf2out_finish, at
dwarf2out.c:22494 when building Firefox's libxul
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: markus@trippelsdorf.de
Created attachment 26152
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26152
testcase patch
Firefox's libxul fails to build with -flto and -g:
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22494
I've delta reduced the failure to two files and then reduced the
files individually.
Here's what I have thus far:
% patch -p0 < patch
patching file Makefile
patching file test2.ii
patching file test.ii
% make
gcc -r -nostdlib test2.ii test.ii -w -std=gnu++0x -pipe -g -Os -flto
lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22494
Please submit a full bug report
Will keep trying to reduce the files further.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
@ 2011-12-20 12:14 ` rguenth at gcc dot gnu.org
2011-12-20 12:26 ` rguenth at gcc dot gnu.org
` (24 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-20 12:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011-12-20
CC| |rguenth at gcc dot gnu.org
Target Milestone|--- |4.7.0
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-20 12:06:10 UTC ---
Confirmed.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
2011-12-20 12:14 ` [Bug lto/51635] " rguenth at gcc dot gnu.org
@ 2011-12-20 12:26 ` rguenth at gcc dot gnu.org
2011-12-20 14:42 ` rguenth at gcc dot gnu.org
` (23 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-20 12:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-20 12:13:27 UTC ---
(gdb) call debug_tree (context)
<record_type 0x7ffff58bd7e0 nsSVGEffects asm_written QI
...
(gdb) call debug_tree (context->type_common.name)
<type_decl 0x7ffff58ad958 nsSVGEffects
type <record_type 0x7ffff58bd7e0 nsSVGEffects asm_written QI
...
public VOID file /tmp/test2.ii line 3256 col 17
align 8 context <translation_unit_decl 0x7ffff5a42f18 D.2349>>
(gdb) call lookup_type_die (context)
$1 = (struct die_struct *) 0x7ffff58fdd70
(gdb) call debug_tree (node->created_for)
<type_decl 0x7ffff58dc2e0 FramePropertyDescriptor
type <record_type 0x7ffff58bd9d8 FramePropertyDescriptor BLK
...
asm_written used nonlocal VOID file /tmp/test.ii line 2611 col 51
align 1 context <record_type 0x7ffff58bd7e0 nsSVGEffects>
so it's DECL_CONTEXT is a type from a different TU. And indeed in the
types TYPE_FIELDS we have
<type_decl 0x7ffff58ada10 nsSVGEffects
type <record_type 0x7ffff58bd7e0 nsSVGEffects asm_written QI
which is another instance of the TYPE_DECL. That asks for proper merging
of those TYPE_DECLs :(
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
2011-12-20 12:14 ` [Bug lto/51635] " rguenth at gcc dot gnu.org
2011-12-20 12:26 ` rguenth at gcc dot gnu.org
@ 2011-12-20 14:42 ` rguenth at gcc dot gnu.org
2011-12-20 15:15 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-20 14:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-20 14:16:35 UTC ---
It's actually easy to do. We just have to make sure that the TYPE_DECLs we
refer to are those of their type. Thus,
Index: gcc/lto/lto.c
===================================================================
--- gcc/lto/lto.c (revision 182525)
+++ gcc/lto/lto.c (working copy)
@@ -867,7 +867,11 @@ uniquify_nodes (struct data_in *data_in,
if (t == NULL_TREE)
continue;
- if (TREE_CODE (t) == VAR_DECL)
+ if (TYPE_P (t)
+ && TYPE_NAME (t)
+ && TREE_CODE (TYPE_NAME (t)) == TYPE_DECL)
+ TYPE_NAME (t) = TYPE_NAME (TREE_TYPE (TYPE_NAME (t)));
+ else if (TREE_CODE (t) == VAR_DECL)
lto_register_var_decl_in_symtab (data_in, t);
else if (TREE_CODE (t) == FUNCTION_DECL && !DECL_BUILT_IN (t))
lto_register_function_decl_in_symtab (data_in, t);
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (2 preceding siblings ...)
2011-12-20 14:42 ` rguenth at gcc dot gnu.org
@ 2011-12-20 15:15 ` rguenth at gcc dot gnu.org
2011-12-20 15:38 ` markus at trippelsdorf dot de
` (21 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-20 15:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-20 14:47:25 UTC ---
Doesn't work. Instead testing a similar
Index: gcc/lto/lto.c
===================================================================
--- gcc/lto/lto.c (revision 182525)
+++ gcc/lto/lto.c (working copy)
@@ -845,6 +845,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;
+ }
}
}
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (3 preceding siblings ...)
2011-12-20 15:15 ` rguenth at gcc dot gnu.org
@ 2011-12-20 15:38 ` markus at trippelsdorf dot de
2011-12-20 15:40 ` rguenther at suse dot de
` (20 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: markus at trippelsdorf dot de @ 2011-12-20 15:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #5 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-20 15:31:47 UTC ---
(In reply to comment #4)
> Doesn't work. Instead testing a similar
>
> Index: gcc/lto/lto.c
> ===================================================================
> --- gcc/lto/lto.c (revision 182525)
> +++ gcc/lto/lto.c (working copy)
> @@ -845,6 +845,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;
> + }
> }
> }
This one is extremely slow. lto1 has already used 12min of CPU time when
linking libxul and is still running... (3min is normal)
"perf top" shows:
27.92% lto1 [.] lto_read_decls
14.79% lto1 [.] htab_find_slot_with_hash
9.37% lto1 [.] gimple_type_eq
6.39% libc-2.14.90.so [.] _int_malloc
5.60% [kernel] [k] 0xffffffff81037d72
4.80% lto1 [.] gtc_visit
3.68% libc-2.14.90.so [.] memset
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (4 preceding siblings ...)
2011-12-20 15:38 ` markus at trippelsdorf dot de
@ 2011-12-20 15:40 ` rguenther at suse dot de
2011-12-20 15:49 ` rguenther at suse dot de
` (19 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenther at suse dot de @ 2011-12-20 15:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-20 15:38:16 UTC ---
On Tue, 20 Dec 2011, markus at trippelsdorf dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
>
> --- Comment #5 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-20 15:31:47 UTC ---
> (In reply to comment #4)
> > Doesn't work. Instead testing a similar
> >
> > Index: gcc/lto/lto.c
> > ===================================================================
> > --- gcc/lto/lto.c (revision 182525)
> > +++ gcc/lto/lto.c (working copy)
> > @@ -845,6 +845,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;
> > + }
> > }
> > }
>
> This one is extremely slow. lto1 has already used 12min of CPU time when
> linking libxul and is still running... (3min is normal)
>
> "perf top" shows:
> 27.92% lto1 [.] lto_read_decls
> 14.79% lto1 [.] htab_find_slot_with_hash
> 9.37% lto1 [.] gimple_type_eq
> 6.39% libc-2.14.90.so [.] _int_malloc
> 5.60% [kernel] [k] 0xffffffff81037d72
> 4.80% lto1 [.] gtc_visit
> 3.68% libc-2.14.90.so [.] memset
That's odd - TREE_TYPE (f1) should already be registered - but I suppose
that adjusting TYPE_NAME might break all the caching we do with the
type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
type we change that SCC by that adjustment - probably causing
the hit rate of the type-pair compare cache to become absymal?
Maybe you can check that theory (I have no other idea why the above
should be slow).
Richard.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (5 preceding siblings ...)
2011-12-20 15:40 ` rguenther at suse dot de
@ 2011-12-20 15:49 ` rguenther at suse dot de
2011-12-20 18:12 ` markus at trippelsdorf dot de
` (18 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenther at suse dot de @ 2011-12-20 15:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-20 15:40:01 UTC ---
On Tue, 20 Dec 2011, Richard Guenther wrote:
> On Tue, 20 Dec 2011, markus at trippelsdorf dot de wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
> >
> > --- Comment #5 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-20 15:31:47 UTC ---
> > (In reply to comment #4)
> > > Doesn't work. Instead testing a similar
> > >
> > > Index: gcc/lto/lto.c
> > > ===================================================================
> > > --- gcc/lto/lto.c (revision 182525)
> > > +++ gcc/lto/lto.c (working copy)
> > > @@ -845,6 +845,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;
> > > + }
> > > }
> > > }
> >
> > This one is extremely slow. lto1 has already used 12min of CPU time when
> > linking libxul and is still running... (3min is normal)
> >
> > "perf top" shows:
> > 27.92% lto1 [.] lto_read_decls
> > 14.79% lto1 [.] htab_find_slot_with_hash
> > 9.37% lto1 [.] gimple_type_eq
> > 6.39% libc-2.14.90.so [.] _int_malloc
> > 5.60% [kernel] [k] 0xffffffff81037d72
> > 4.80% lto1 [.] gtc_visit
> > 3.68% libc-2.14.90.so [.] memset
>
> That's odd - TREE_TYPE (f1) should already be registered - but I suppose
> that adjusting TYPE_NAME might break all the caching we do with the
> type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
> type we change that SCC by that adjustment - probably causing
> the hit rate of the type-pair compare cache to become absymal?
> Maybe you can check that theory (I have no other idea why the above
> should be slow).
Though we should be hitting the gimple_type_leader cache only ...
maybe it's too small though?
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (6 preceding siblings ...)
2011-12-20 15:49 ` rguenther at suse dot de
@ 2011-12-20 18:12 ` markus at trippelsdorf dot de
2011-12-21 9:38 ` rguenth at gcc dot gnu.org
` (17 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: markus at trippelsdorf dot de @ 2011-12-20 18:12 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #8 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-20 18:06:34 UTC ---
(In reply to comment #7)
> On Tue, 20 Dec 2011, Richard Guenther wrote:
> > > This one is extremely slow. lto1 has already used 12min of CPU time when
> > > linking libxul and is still running... (3min is normal)
> >
> > That's odd - TREE_TYPE (f1) should already be registered - but I suppose
> > that adjusting TYPE_NAME might break all the caching we do with the
> > type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
> > type we change that SCC by that adjustment - probably causing
> > the hit rate of the type-pair compare cache to become absymal?
> > Maybe you can check that theory (I have no other idea why the above
> > should be slow).
>
> Though we should be hitting the gimple_type_leader cache only ...
> maybe it's too small though?
Increasing the cache 4-fold doesn't help.
I will look deeper tomorrow. In the meantime here is a disassembly of the
hot-spot.
uniquify_nodes:
: /* Second fixup all trees in the new cache entries. */
: for (i = len; i-- > from;)
0.00 : 49969f: mov %ebp,%eax
0.00 : 4996a1: jmpq 4994b0 <lto_read_decls+0x110>
0.00 : 4996a6: nopw %cs:0x0(%rax,%rax,1)
: tree t = VEC_index (tree, cache->nodes, i);
: if (t == NULL_TREE)
: continue;
:
: if (TREE_CODE (t) == VAR_DECL)
: lto_register_var_decl_in_symtab (data_in, t);
0.00 : 4996b0: mov 0x38(%rsp),%rdi
0.00 : 4996b5: callq 499250
<lto_register_var_decl_in_symtab>
0.00 : 4996ba: jmpq 499520 <lto_read_decls+0x180>
: variant list state before fixup is broken. */
: tree tem, mv;
:
: /* Remove us from our main variant list if we are
not the
: variant leader. */
: if (TYPE_MAIN_VARIANT (t) != t)
0.00 : 4996bf: mov 0x68(%r15),%rdi
0.00 : 4996c3: cmp %rdi,%r15
0.00 : 4996c6: je 499701 <lto_read_decls+0x361>
: {
: tem = TYPE_MAIN_VARIANT (t);
: while (tem && TYPE_NEXT_VARIANT (tem) != t)
0.00 : 4996c8: test %rdi,%rdi
0.00 : 4996cb: je 4996f9 <lto_read_decls+0x359>
0.00 : 4996cd: mov 0x60(%rdi),%rax
0.00 : 4996d1: cmp %rax,%r15
0.00 : 4996d4: jne 4996e3 <lto_read_decls+0x343>
0.00 : 4996d6: jmpq 4997d9 <lto_read_decls+0x439>
0.00 : 4996db: nopl 0x0(%rax,%rax,1)
0.50 : 4996e0: mov %rcx,%rax
0.70 : 4996e3: test %rax,%rax
0.00 : 4996e6: je 4996f9 <lto_read_decls+0x359>
0.00 : 4996e8: mov 0x60(%rax),%rcx
98.41 : 4996ec: cmp %rcx,%r15
0.00 : 4996ef: jne 4996e0 <lto_read_decls+0x340>
: tem = TYPE_NEXT_VARIANT (tem);
: if (tem)
: TYPE_NEXT_VARIANT (tem) = TYPE_NEXT_VARIANT
(t);
0.00 : 4996f1: mov 0x60(%r15),%rcx
0.00 : 4996f5: mov %rcx,0x60(%rax)
: TYPE_NEXT_VARIANT (t) = NULL_TREE;
0.00 : 4996f9: movq $0x0,0x60(%r15)
: }
:
: /* Query our new main variant. */
: mv = gimple_register_type (TYPE_MAIN_VARIANT (t));
0.01 : 499701: callq 5be860 <gimple_register_type>
:
: /* If we were the variant leader and we get
replaced ourselves drop
: all variants from our list. */
: if (TYPE_MAIN_VARIANT (t) == t
0.00 : 499706: mov 0x30(%rsp),%rdx
0.00 : 49970b: cmp 0x68(%rdx),%rdx
0.00 : 49970f: je 4997b7 <lto_read_decls+0x417>
: }
: }
:
: /* If we are not our own variant leader link us
into our new leaders
: variant list. */
: if (mv != t)
0.00 : 499715: cmp %rax,0x30(%rsp)
0.00 : 49971a: je 49992d <lto_read_decls+0x58d>
: {
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (7 preceding siblings ...)
2011-12-20 18:12 ` markus at trippelsdorf dot de
@ 2011-12-21 9:38 ` rguenth at gcc dot gnu.org
2011-12-21 9:48 ` markus at trippelsdorf dot de
` (16 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 9:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 09:29:05 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > On Tue, 20 Dec 2011, Richard Guenther wrote:
> > > > This one is extremely slow. lto1 has already used 12min of CPU time when
> > > > linking libxul and is still running... (3min is normal)
> > >
> > > That's odd - TREE_TYPE (f1) should already be registered - but I suppose
> > > that adjusting TYPE_NAME might break all the caching we do with the
> > > type-pair cache as TREE_TYPE (TYPE_NAME (f1)) is in the SCC of the
> > > type we change that SCC by that adjustment - probably causing
> > > the hit rate of the type-pair compare cache to become absymal?
> > > Maybe you can check that theory (I have no other idea why the above
> > > should be slow).
> >
> > Though we should be hitting the gimple_type_leader cache only ...
> > maybe it's too small though?
>
> Increasing the cache 4-fold doesn't help.
> I will look deeper tomorrow. In the meantime here is a disassembly of the
> hot-spot.
>
> uniquify_nodes:
> : /* Second fixup all trees in the new cache entries. */
> : for (i = len; i-- > from;)
> 0.00 : 49969f: mov %ebp,%eax
> 0.00 : 4996a1: jmpq 4994b0 <lto_read_decls+0x110>
> 0.00 : 4996a6: nopw %cs:0x0(%rax,%rax,1)
> : tree t = VEC_index (tree, cache->nodes, i);
> : if (t == NULL_TREE)
> : continue;
> :
> : if (TREE_CODE (t) == VAR_DECL)
> : lto_register_var_decl_in_symtab (data_in, t);
> 0.00 : 4996b0: mov 0x38(%rsp),%rdi
> 0.00 : 4996b5: callq 499250
> <lto_register_var_decl_in_symtab>
> 0.00 : 4996ba: jmpq 499520 <lto_read_decls+0x180>
> : variant list state before fixup is broken. */
> : tree tem, mv;
> :
> : /* Remove us from our main variant list if we are
> not the
> : variant leader. */
> : if (TYPE_MAIN_VARIANT (t) != t)
> 0.00 : 4996bf: mov 0x68(%r15),%rdi
> 0.00 : 4996c3: cmp %rdi,%r15
> 0.00 : 4996c6: je 499701 <lto_read_decls+0x361>
> : {
> : tem = TYPE_MAIN_VARIANT (t);
> : while (tem && TYPE_NEXT_VARIANT (tem) != t)
> 0.00 : 4996c8: test %rdi,%rdi
> 0.00 : 4996cb: je 4996f9 <lto_read_decls+0x359>
> 0.00 : 4996cd: mov 0x60(%rdi),%rax
> 0.00 : 4996d1: cmp %rax,%r15
> 0.00 : 4996d4: jne 4996e3 <lto_read_decls+0x343>
> 0.00 : 4996d6: jmpq 4997d9 <lto_read_decls+0x439>
> 0.00 : 4996db: nopl 0x0(%rax,%rax,1)
> 0.50 : 4996e0: mov %rcx,%rax
> 0.70 : 4996e3: test %rax,%rax
> 0.00 : 4996e6: je 4996f9 <lto_read_decls+0x359>
> 0.00 : 4996e8: mov 0x60(%rax),%rcx
> 98.41 : 4996ec: cmp %rcx,%r15
> 0.00 : 4996ef: jne 4996e0 <lto_read_decls+0x340>
> : tem = TYPE_NEXT_VARIANT (tem);
> : if (tem)
> : TYPE_NEXT_VARIANT (tem) = TYPE_NEXT_VARIANT
> (t);
> 0.00 : 4996f1: mov 0x60(%r15),%rcx
> 0.00 : 4996f5: mov %rcx,0x60(%rax)
> : TYPE_NEXT_VARIANT (t) = NULL_TREE;
> 0.00 : 4996f9: movq $0x0,0x60(%r15)
> : }
> :
> : /* Query our new main variant. */
> : mv = gimple_register_type (TYPE_MAIN_VARIANT (t));
> 0.01 : 499701: callq 5be860 <gimple_register_type>
> :
> : /* If we were the variant leader and we get
> replaced ourselves drop
> : all variants from our list. */
> : if (TYPE_MAIN_VARIANT (t) == t
> 0.00 : 499706: mov 0x30(%rsp),%rdx
> 0.00 : 49970b: cmp 0x68(%rdx),%rdx
> 0.00 : 49970f: je 4997b7 <lto_read_decls+0x417>
> : }
> : }
> :
> : /* If we are not our own variant leader link us
> into our new leaders
> : variant list. */
> : if (mv != t)
> 0.00 : 499715: cmp %rax,0x30(%rsp)
> 0.00 : 49971a: je 49992d <lto_read_decls+0x58d>
> : {
That's weird. Did the build eventually finish? LTO bootstrap went fine
for me, but SPEC 2k6 483.xalancbmk build ran out of memory during LTRANs
(in theory we should end up using _less_ memory with the change ...)
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (8 preceding siblings ...)
2011-12-21 9:38 ` rguenth at gcc dot gnu.org
@ 2011-12-21 9:48 ` markus at trippelsdorf dot de
2011-12-21 11:04 ` rguenth at gcc dot gnu.org
` (15 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: markus at trippelsdorf dot de @ 2011-12-21 9:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #10 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-21 09:37:38 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > On Tue, 20 Dec 2011, Richard Guenther wrote:
> That's weird. Did the build eventually finish? LTO bootstrap went fine
> for me, but SPEC 2k6 483.xalancbmk build ran out of memory during LTRANs
> (in theory we should end up using _less_ memory with the change ...)
Yes. It did "finish" after using ~17min of CPU-time, but only to hit the next
bug:
/var/tmp/mozilla-central/parser/htmlparser/src/nsScannerString.cpp:124:46:
internal compiler error: in force_type_die, at dwarf2out.c:19296
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (9 preceding siblings ...)
2011-12-21 9:48 ` markus at trippelsdorf dot de
@ 2011-12-21 11:04 ` rguenth at gcc dot gnu.org
2011-12-21 11:17 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 11:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 10:56:01 UTC ---
One issue we still hit is that we for example merge in
stl_iterator_base_types.h
template<typename _Iterator>
struct iterator_traits
{
typedef typename _Iterator::iterator_category iterator_category;
typedef typename _Iterator::value_type value_type;
typedef typename _Iterator::difference_type difference_type;
typedef typename _Iterator::pointer pointer;
typedef typename _Iterator::reference reference;
};
and
template<typename _Tp>
struct iterator_traits<const _Tp*>
{
typedef random_access_iterator_tag iterator_category;
typedef _Tp value_type;
typedef ptrdiff_t difference_type;
typedef const _Tp* pointer;
typedef const _Tp& reference;
};
and so end up attaching the same TYPE_DECL to both iterator_category typedefs.
An extreme idea was to only merge if the TYPE_DECLs source location was the
same (but not sure if that works reliably without expensive location
expansion).
The above merging causes us to infinitely recurse in modified_type_die
through DECL_ORIGINAL_TYPE which forms a typedef cycle. You probably
hit a similar bug.
A non-optimial patch for the above is (non-optimal because it does not
include hashing)
Index: gcc/gimple.c
===================================================================
--- gcc/gimple.c (revision 182525)
+++ gcc/gimple.c (working copy)
@@ -3318,28 +3318,35 @@ compare_type_names_p (tree t1, tree t2)
tree name1 = TYPE_NAME (t1);
tree name2 = TYPE_NAME (t2);
+ if (name1 == name2)
+ return true;
+
if ((name1 != NULL_TREE) != (name2 != NULL_TREE))
return false;
- if (name1 == NULL_TREE)
- return true;
-
/* Either both should be a TYPE_DECL or both an IDENTIFIER_NODE. */
if (TREE_CODE (name1) != TREE_CODE (name2))
return false;
if (TREE_CODE (name1) == TYPE_DECL)
- name1 = DECL_NAME (name1);
- gcc_checking_assert (!name1 || TREE_CODE (name1) == IDENTIFIER_NODE);
+ {
+ expanded_location loc1, loc2;
- if (TREE_CODE (name2) == TYPE_DECL)
- name2 = DECL_NAME (name2);
- gcc_checking_assert (!name2 || TREE_CODE (name2) == IDENTIFIER_NODE);
+ if (DECL_NAME (name1) != DECL_NAME (name2))
+ return false;
- /* Identifiers can be compared with pointer equality rather
- than a string comparison. */
- if (name1 == name2)
- return true;
+ if (DECL_SOURCE_LOCATION (name1) == DECL_SOURCE_LOCATION (name2))
+ return true;
+
+ loc1 = expand_location (DECL_SOURCE_LOCATION (name1));
+ loc2 = expand_location (DECL_SOURCE_LOCATION (name2));
+ if (loc1.line != loc2.line
+ || loc1.column != loc2.column
+ || strcmp (loc1.file, loc2.file) != 0)
+ return false;
+
+ return true;
+ }
return false;
}
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (10 preceding siblings ...)
2011-12-21 11:04 ` rguenth at gcc dot gnu.org
@ 2011-12-21 11:17 ` rguenth at gcc dot gnu.org
2011-12-21 12:58 ` markus at trippelsdorf dot de
` (13 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 11:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 11:03:46 UTC ---
Created attachment 26158
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26158
patch candidate to speed up uniquify nodes
I was also experimenting with the attached patch - it should be enough to
call gimple_register_types (in uniquify_nodes and lto_fixup_types and friends)
for types in the current set of trees we process, and for those that do not
prevail.
[asserting that does not work though, for unknown reasons - known partially
at least for pre-loaded types which we shouldn't really merge anyway]
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (11 preceding siblings ...)
2011-12-21 11:17 ` rguenth at gcc dot gnu.org
@ 2011-12-21 12:58 ` markus at trippelsdorf dot de
2011-12-21 12:59 ` rguenth at gcc dot gnu.org
` (12 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: markus at trippelsdorf dot de @ 2011-12-21 12:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #13 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-21 12:55:21 UTC ---
(In reply to comment #11)
> One issue we still hit is that we for example merge in
> stl_iterator_base_types.h
>
> template<typename _Iterator>
> struct iterator_traits
> {
> typedef typename _Iterator::iterator_category iterator_category;
> typedef typename _Iterator::value_type value_type;
> typedef typename _Iterator::difference_type difference_type;
> typedef typename _Iterator::pointer pointer;
> typedef typename _Iterator::reference reference;
> };
>
> and
>
> template<typename _Tp>
> struct iterator_traits<const _Tp*>
> {
> typedef random_access_iterator_tag iterator_category;
> typedef _Tp value_type;
> typedef ptrdiff_t difference_type;
> typedef const _Tp* pointer;
> typedef const _Tp& reference;
> };
>
> and so end up attaching the same TYPE_DECL to both iterator_category typedefs.
> An extreme idea was to only merge if the TYPE_DECLs source location was the
> same (but not sure if that works reliably without expensive location
> expansion).
>
> The above merging causes us to infinitely recurse in modified_type_die
> through DECL_ORIGINAL_TYPE which forms a typedef cycle. You probably
> hit a similar bug.
>
> A non-optimial patch for the above is (non-optimal because it does not
> include hashing)
>
> Index: gcc/gimple.c
> ===================================================================
> --- gcc/gimple.c (revision 182525)
> +++ gcc/gimple.c (working copy)
> @@ -3318,28 +3318,35 @@ compare_type_names_p (tree t1, tree t2)
> tree name1 = TYPE_NAME (t1);
> tree name2 = TYPE_NAME (t2);
>
> + if (name1 == name2)
> + return true;
> +
> if ((name1 != NULL_TREE) != (name2 != NULL_TREE))
> return false;
>
> - if (name1 == NULL_TREE)
> - return true;
> -
> /* Either both should be a TYPE_DECL or both an IDENTIFIER_NODE. */
> if (TREE_CODE (name1) != TREE_CODE (name2))
> return false;
>
> if (TREE_CODE (name1) == TYPE_DECL)
> - name1 = DECL_NAME (name1);
> - gcc_checking_assert (!name1 || TREE_CODE (name1) == IDENTIFIER_NODE);
> + {
> + expanded_location loc1, loc2;
>
> - if (TREE_CODE (name2) == TYPE_DECL)
> - name2 = DECL_NAME (name2);
> - gcc_checking_assert (!name2 || TREE_CODE (name2) == IDENTIFIER_NODE);
> + if (DECL_NAME (name1) != DECL_NAME (name2))
> + return false;
>
> - /* Identifiers can be compared with pointer equality rather
> - than a string comparison. */
> - if (name1 == name2)
> - return true;
> + if (DECL_SOURCE_LOCATION (name1) == DECL_SOURCE_LOCATION (name2))
> + return true;
> +
> + loc1 = expand_location (DECL_SOURCE_LOCATION (name1));
> + loc2 = expand_location (DECL_SOURCE_LOCATION (name2));
> + if (loc1.line != loc2.line
> + || loc1.column != loc2.column
> + || strcmp (loc1.file, loc2.file) != 0)
> + return false;
> +
> + return true;
> + }
>
> return false;
> }
Program received signal SIGSEGV, Segmentation fault.
[Switching to process 30844]
strcmp () at ../sysdeps/x86_64/strcmp.S:214
214 movlpd (%rsi), %xmm2
(gdb) bt
#0 strcmp () at ../sysdeps/x86_64/strcmp.S:214
#1 0x00000000005bff0f in compare_type_names_p (t1=<optimized out>,
t2=<optimized out>) at ../../gcc/gcc/gimple.c:3345
#2 gimple_types_compatible_p_1 (t1=0x7ffff6feb000, t2=0x7ffff728f690,
p=0x10ea9dc, sccstack=0x7ffffffee068, sccstate=0x1118380,
sccstate_obstack=0x7ffffffee070) at ../../gcc/gcc/gimple.c:3554
#3 0x00000000005bea20 in gimple_types_compatible_p (t2=0x7ffff728f690,
t1=0x7ffff6feb000) at ../../gcc/gcc/gimple.c:3943
#4 gimple_type_eq (p1=0x7ffff6feb000, p2=0x7ffff728f690) at
../../gcc/gcc/gimple.c:4438
#5 0x0000000000b6f064 in htab_find_slot_with_hash (htab=0x7ffff727db60,
element=0x7ffff728f690, hash=1226149484, insert=INSERT)
at ../../gcc/libiberty/hashtab.c:668
#6 0x00000000005b87d1 in gimple_register_type_1 (t=0x7ffff728f690,
registering_mv=<optimized out>) at ../../gcc/gcc/gimple.c:4473
#7 0x00000000005b8803 in gimple_register_type_1 (t=0x7ffff6fc1540,
registering_mv=<optimized out>) at ../../gcc/gcc/gimple.c:4470
#8 0x00000000004996d4 in uniquify_nodes (data_in=0x10bb2b0, from=236) at
../../gcc/gcc/lto/lto.c:742
#9 0x0000000000499b13 in lto_read_decls (decl_data=0x7ffff73bf000,
data=0x7ffff718e020, resolutions=<optimized out>) at
../../gcc/gcc/lto/lto.c:933
#10 0x000000000049ab80 in lto_file_finalize (file_data=0x7ffff73bf000,
file=<optimized out>) at ../../gcc/gcc/lto/lto.c:1173
#11 lto_create_files_from_ids (count=<synthetic pointer>,
file_data=0x7ffff73bf000, file=0x1028eb0) at ../../gcc/gcc/lto/lto.c:1183
#12 lto_file_read (count=<synthetic pointer>, resolution_file=0x10b70b0,
file=0x1028eb0) at ../../gcc/gcc/lto/lto.c:1223
#13 read_cgraph_and_symbols (fnames=0x103ac10, nfiles=110) at
../../gcc/gcc/lto/lto.c:2624
#14 lto_main () at ../../gcc/gcc/lto/lto.c:2938
#15 0x00000000006f5b24 in compile_file () at ../../gcc/gcc/toplev.c:557
#16 do_compile () at ../../gcc/gcc/toplev.c:1935
#17 toplev_main (argc=173, argv=0x10130d0) at ../../gcc/gcc/toplev.c:2011
#18 0x00007ffff7895425 in __libc_start_main (main=0x49ea50 <main>, argc=64,
ubp_av=0x7fffffffdb58, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffdb48) at libc-start.c:226
#19 0
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (12 preceding siblings ...)
2011-12-21 12:58 ` markus at trippelsdorf dot de
@ 2011-12-21 12:59 ` rguenth at gcc dot gnu.org
2011-12-21 13:01 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 12:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 12:57:58 UTC ---
Created attachment 26160
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26160
patch comparing DECL_SOURCE_LOCATION
Fixed patch, also with hashing adjustments.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (13 preceding siblings ...)
2011-12-21 12:59 ` rguenth at gcc dot gnu.org
@ 2011-12-21 13:01 ` rguenth at gcc dot gnu.org
2011-12-21 13:48 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 13:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #26158|0 |1
is obsolete| |
--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 12:58:54 UTC ---
Created attachment 26161
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26161
patch speeding up uniquify_nodes
Patch to speedup uniquify_nodes
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (14 preceding siblings ...)
2011-12-21 13:01 ` rguenth at gcc dot gnu.org
@ 2011-12-21 13:48 ` rguenth at gcc dot gnu.org
2011-12-21 14:01 ` markus at trippelsdorf dot de
` (9 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 13:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #16 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 13:00:37 UTC ---
Created attachment 26162
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26162
patch for this bug
And finally the patch for this particular bug, to be applied ontop of the
previous two.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (15 preceding siblings ...)
2011-12-21 13:48 ` rguenth at gcc dot gnu.org
@ 2011-12-21 14:01 ` markus at trippelsdorf dot de
2011-12-21 14:08 ` rguenther at suse dot de
` (8 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: markus at trippelsdorf dot de @ 2011-12-21 14:01 UTC (permalink / raw)
To: gcc-bugs
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
:-(
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++;
:
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (16 preceding siblings ...)
2011-12-21 14:01 ` markus at trippelsdorf dot de
@ 2011-12-21 14:08 ` rguenther at suse dot de
2011-12-21 15:07 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenther at suse dot de @ 2011-12-21 14:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (17 preceding siblings ...)
2011-12-21 14:08 ` rguenther at suse dot de
@ 2011-12-21 15:07 ` rguenth at gcc dot gnu.org
2011-12-21 15:11 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 15:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 15:00:21 UTC ---
Btw, one issue with merging based on DECL_SOURCE_LOCATION is that reducing
LTO testcases is going to be disrupted by source line changes. So for it
to be effective one would need to preserve #include directives and reduce
headers together with sources (ugh).
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (18 preceding siblings ...)
2011-12-21 15:07 ` rguenth at gcc dot gnu.org
@ 2011-12-21 15:11 ` rguenth at gcc dot gnu.org
2011-12-21 15:51 ` markus at trippelsdorf dot de
` (5 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 15:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #20 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 15:06:35 UTC ---
(In reply to comment #19)
> Btw, one issue with merging based on DECL_SOURCE_LOCATION is that reducing
> LTO testcases is going to be disrupted by source line changes. So for it
> to be effective one would need to preserve #include directives and reduce
> headers together with sources (ugh).
Which means - can you check (on the original sources) whether just
using the patch comparing DECL_SOURCE_LOCATION fixes the bug
(yeah, and runs into the new bug...)
Btw, my fear of crossing SCCs should not really happen unless we have such
bogus merging like outlined in comment #11.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (19 preceding siblings ...)
2011-12-21 15:11 ` rguenth at gcc dot gnu.org
@ 2011-12-21 15:51 ` markus at trippelsdorf dot de
2011-12-21 16:02 ` rguenther at suse dot de
` (4 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: markus at trippelsdorf dot de @ 2011-12-21 15:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #21 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-21 15:47:01 UTC ---
(In reply to comment #20)
> (In reply to comment #19)
> > Btw, one issue with merging based on DECL_SOURCE_LOCATION is that reducing
> > LTO testcases is going to be disrupted by source line changes. So for it
> > to be effective one would need to preserve #include directives and reduce
> > headers together with sources (ugh).
>
> Which means - can you check (on the original sources) whether just
> using the patch comparing DECL_SOURCE_LOCATION fixes the bug
> (yeah, and runs into the new bug...)
Yes, this patch alone fixes this bug. (and runs into the new one
from Comment 17)
(3.5 minutes CPU-time, 5GB RAM used, 3.1GB ltrans files written out)
BTW a quick debugging question:
Is it possible to tell lto1 to use partitions even when called
directly in a delta check script? (I have only 8GB of RAM
and calling lto1 directly uses ~15GB. (I've used a big swapfile
on my SSD when reduceing this bug))
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (20 preceding siblings ...)
2011-12-21 15:51 ` markus at trippelsdorf dot de
@ 2011-12-21 16:02 ` rguenther at suse dot de
2011-12-21 16:09 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenther at suse dot de @ 2011-12-21 16:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-21 15:51:16 UTC ---
On Wed, 21 Dec 2011, markus at trippelsdorf dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
>
> --- Comment #21 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-21 15:47:01 UTC ---
> (In reply to comment #20)
> > (In reply to comment #19)
> > > Btw, one issue with merging based on DECL_SOURCE_LOCATION is that reducing
> > > LTO testcases is going to be disrupted by source line changes. So for it
> > > to be effective one would need to preserve #include directives and reduce
> > > headers together with sources (ugh).
> >
> > Which means - can you check (on the original sources) whether just
> > using the patch comparing DECL_SOURCE_LOCATION fixes the bug
> > (yeah, and runs into the new bug...)
>
>
> Yes, this patch alone fixes this bug. (and runs into the new one
> from Comment 17)
Thanks. New testcase appreciated ;)
> (3.5 minutes CPU-time, 5GB RAM used, 3.1GB ltrans files written out)
>
> BTW a quick debugging question:
> Is it possible to tell lto1 to use partitions even when called
> directly in a delta check script? (I have only 8GB of RAM
> and calling lto1 directly uses ~15GB. (I've used a big swapfile
> on my SSD when reduceing this bug))
Hmm, I always use the xgcc or g++ drivers for reducing LTO bugs.
To use partitions more "manually" you'd have to invoke lto-wrapper
(or emulate what it does).
Richard.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (21 preceding siblings ...)
2011-12-21 16:02 ` rguenther at suse dot de
@ 2011-12-21 16:09 ` rguenth at gcc dot gnu.org
2011-12-21 16:44 ` matz at gcc dot gnu.org
` (2 subsequent siblings)
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-12-21 16:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #23 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-12-21 16:01:30 UTC ---
Another fun (well ...) patch that is worth trying is
Index: gcc/gimple.c
===================================================================
--- gcc/gimple.c (revision 182590)
+++ gcc/gimple.c (working copy)
@@ -4488,16 +4488,7 @@ gimple_register_type_1 (tree t, bool reg
tree
gimple_register_type (tree t)
{
- gcc_assert (TYPE_P (t));
-
- if (!gimple_type_leader)
- gimple_type_leader = ggc_alloc_cleared_vec_gimple_type_leader_entry_s
- (GIMPLE_TYPE_LEADER_SIZE);
-
- if (gimple_types == NULL)
- gimple_types = htab_create_ggc (16381, gimple_type_hash, gimple_type_eq,
0);
-
- return gimple_register_type_1 (t, false);
+ return t;
}
/* The TYPE_CANONICAL merging machinery. It should closely resemble
where you need to configure with --disable-werror (because of now unused
functions in gimple.c). The above will simply disable all type merging
and thus may in theory increase memory usage a lot (I think so more for
ltrans stage than wpa stage, it also may increase ltrans file size a lot).
It also probably increases the size of the emitted debug information.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (22 preceding siblings ...)
2011-12-21 16:09 ` rguenth at gcc dot gnu.org
@ 2011-12-21 16:44 ` matz at gcc dot gnu.org
2011-12-22 10:15 ` markus at trippelsdorf dot de
2012-01-03 11:34 ` [Bug lto/51635] LTO should not merge (type) decls with different locations rguenth at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: matz at gcc dot gnu.org @ 2011-12-21 16:44 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Michael Matz <matz at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |matz at gcc dot gnu.org
--- Comment #24 from Michael Matz <matz at gcc dot gnu.org> 2011-12-21 16:39:32 UTC ---
(just FYI: my later LTO patches do merge some decls, amongst them TYPE_DECLs)
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (23 preceding siblings ...)
2011-12-21 16:44 ` matz at gcc dot gnu.org
@ 2011-12-22 10:15 ` markus at trippelsdorf dot de
2012-01-03 11:34 ` [Bug lto/51635] LTO should not merge (type) decls with different locations rguenth at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: markus at trippelsdorf dot de @ 2011-12-22 10:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #25 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-22 09:48:27 UTC ---
(In reply to comment #23)
> Another fun (well ...) patch that is worth trying is
>
> Index: gcc/gimple.c
> ===================================================================
> --- gcc/gimple.c (revision 182590)
> +++ gcc/gimple.c (working copy)
> @@ -4488,16 +4488,7 @@ gimple_register_type_1 (tree t, bool reg
> tree
> gimple_register_type (tree t)
> {
> - gcc_assert (TYPE_P (t));
> -
> - if (!gimple_type_leader)
> - gimple_type_leader = ggc_alloc_cleared_vec_gimple_type_leader_entry_s
> - (GIMPLE_TYPE_LEADER_SIZE);
> -
> - if (gimple_types == NULL)
> - gimple_types = htab_create_ggc (16381, gimple_type_hash, gimple_type_eq,
> 0);
> -
> - return gimple_register_type_1 (t, false);
> + return t;
> }
>
> /* The TYPE_CANONICAL merging machinery. It should closely resemble
>
> where you need to configure with --disable-werror (because of now unused
> functions in gimple.c). The above will simply disable all type merging
> and thus may in theory increase memory usage a lot (I think so more for
> ltrans stage than wpa stage, it also may increase ltrans file size a lot).
> It also probably increases the size of the emitted debug information.
Not really feasible:
13.5 minutes CPU-time, 7.5GB RAM used, 6.3GB ltrans files
(and then lto1 on the individual partitions also takes ~2min per instance)
88.80% lto1 [.] lto_read_decls
0.51% lto1 [.] htab_expand
0.42% libz.so.1.2.5.1 [.] inflate_fast
0.35% lto1 [.] htab_find_slot_with_hash
0.30% lto1 [.] gimple_canonical_types_compatible_p
^ permalink raw reply [flat|nested] 27+ messages in thread
* [Bug lto/51635] LTO should not merge (type) decls with different locations
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
` (24 preceding siblings ...)
2011-12-22 10:15 ` markus at trippelsdorf dot de
@ 2012-01-03 11:34 ` rguenth at gcc dot gnu.org
25 siblings, 0 replies; 27+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-01-03 11:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.7.0 |---
Summary|[4.7 regression] ICE in in |LTO should not merge (type)
|dwarf2out_finish, at |decls with different
|dwarf2out.c:22494 when |locations
|building Firefox's libxul |
Severity|normal |enhancement
--- Comment #26 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-03 11:33:20 UTC ---
Keeping this bug as an enhancement (the debug-info will be bogus for
templates otherwise). The fix for PR51650 fixed the original ICE.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2012-01-03 11:34 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-20 12:06 [Bug lto/51635] New: [4.7 regression] ICE in in dwarf2out_finish, at dwarf2out.c:22494 when building Firefox's libxul markus at trippelsdorf dot de
2011-12-20 12:14 ` [Bug lto/51635] " rguenth at gcc dot gnu.org
2011-12-20 12:26 ` rguenth at gcc dot gnu.org
2011-12-20 14:42 ` rguenth at gcc dot gnu.org
2011-12-20 15:15 ` rguenth at gcc dot gnu.org
2011-12-20 15:38 ` markus at trippelsdorf dot de
2011-12-20 15:40 ` rguenther at suse dot de
2011-12-20 15:49 ` rguenther at suse dot de
2011-12-20 18:12 ` markus at trippelsdorf dot de
2011-12-21 9:38 ` rguenth at gcc dot gnu.org
2011-12-21 9:48 ` markus at trippelsdorf dot de
2011-12-21 11:04 ` rguenth at gcc dot gnu.org
2011-12-21 11:17 ` rguenth at gcc dot gnu.org
2011-12-21 12:58 ` markus at trippelsdorf dot de
2011-12-21 12:59 ` rguenth at gcc dot gnu.org
2011-12-21 13:01 ` rguenth at gcc dot gnu.org
2011-12-21 13:48 ` rguenth at gcc dot gnu.org
2011-12-21 14:01 ` markus at trippelsdorf dot de
2011-12-21 14:08 ` rguenther at suse dot de
2011-12-21 15:07 ` rguenth at gcc dot gnu.org
2011-12-21 15:11 ` rguenth at gcc dot gnu.org
2011-12-21 15:51 ` markus at trippelsdorf dot de
2011-12-21 16:02 ` rguenther at suse dot de
2011-12-21 16:09 ` rguenth at gcc dot gnu.org
2011-12-21 16:44 ` matz at gcc dot gnu.org
2011-12-22 10:15 ` markus at trippelsdorf dot de
2012-01-03 11:34 ` [Bug lto/51635] LTO should not merge (type) decls with different locations rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).