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

2011-12-22 Thread markus at trippelsdorf dot de
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

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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

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

2011-12-21 Thread markus at trippelsdorf dot de
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

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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 templatetypename _Iterator struct iterator_traits

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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

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

2011-12-21 Thread markus at trippelsdorf dot de
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 templatetypename _Iterator

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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

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

2011-12-21 Thread markus at trippelsdorf dot de
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:

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

2011-12-21 Thread rguenther at suse dot de
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

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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

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

2011-12-21 Thread markus at trippelsdorf dot de
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

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

2011-12-21 Thread rguenther at suse dot de
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

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

2011-12-21 Thread rguenth at gcc dot gnu.org
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 === ---

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

2011-12-21 Thread matz at gcc dot gnu.org
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

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

2011-12-20 Thread rguenth at gcc dot gnu.org
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

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

2011-12-20 Thread rguenth at gcc dot gnu.org
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 0x758bd7e0 nsSVGEffects asm_written QI ... (gdb) call debug_tree (context-type_common.name) type_decl

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

2011-12-20 Thread rguenth at gcc dot gnu.org
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

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

2011-12-20 Thread rguenth at gcc dot gnu.org
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

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

2011-12-20 Thread markus at trippelsdorf dot de
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

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

2011-12-20 Thread rguenther at suse dot de
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

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

2011-12-20 Thread rguenther at suse dot de
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:

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

2011-12-20 Thread markus at trippelsdorf dot de
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