On Linux/x86-64, revision 182367 configured with --prefix=/usr/local --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld --with-build-config=bootstrap-lto --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc failed to bootstrap-profiled: lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22493 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[7]: *** [/tmp/ccwUcTbd.ltrans29.ltrans.o] Error 1 make[7]: *** Waiting for unfinished jobs.... lto-wrapper: make returned 2 exit status /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[6]: *** [cc1plus] Error 1 Revision 182359 is OK.
It is caused by revision 182367: http://gcc.gnu.org/ml/gcc-cvs/2011-12/msg00505.html
Testcase?
Created attachment 26107 [details] pr51572.i % gcc -w -flto -g pr51572.i lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22493
Sorry, my check.sh script not optimal. Here is a really reduced testcase: % cat test.i struct VdbeOpList { }; typedef struct VdbeOpList VdbeOpList; sqlite3_blob_open () { static VdbeOpList openBlob[] = { }; } % gcc -w -flto -g test.i lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22493
Thanks Marcus. Even more reduced: typedef int T; void fn (void) { static T t; } making it link with adding 'int main() {}' does not affect the failure.
We are creating the typedef DIE as limbo as we create it from here: /* If TYPE is a typedef type variant, let's generate debug info for the parent typedef which TYPE is a type of. */ if (typedef_variant_p (type)) { if (TREE_ASM_WRITTEN (type)) return; /* Prevent broken recursion; we can't hand off to the same type. */ gcc_assert (DECL_ORIGINAL_TYPE (TYPE_NAME (type)) != type); /* Use the DIE of the containing namespace as the parent DIE of the type description DIE we want to generate. */ if (DECL_CONTEXT (TYPE_NAME (type)) && TREE_CODE (DECL_CONTEXT (TYPE_NAME (type))) == NAMESPACE_DECL) context_die = get_context_die (DECL_CONTEXT (TYPE_NAME (type))); TREE_ASM_WRITTEN (type) = 1; gen_decl_die (TYPE_NAME (type), NULL, context_die); and the DECL_CONTEXT of the TYPE_DECL is the translation unit. Not sure why we do not immediately using such kind of context here, similar in the case of is_naming_typedef_decl () below. Thus, the following fixes it: Index: gcc/dwarf2out.c =================================================================== --- gcc/dwarf2out.c (revision 182398) +++ gcc/dwarf2out.c (working copy) @@ -18842,8 +18849,9 @@ gen_type_die_with_usage (tree type, dw_d /* Use the DIE of the containing namespace as the parent DIE of the type description DIE we want to generate. */ - if (DECL_CONTEXT (TYPE_NAME (type)) - && TREE_CODE (DECL_CONTEXT (TYPE_NAME (type))) == NAMESPACE_DECL) + if (DECL_FILE_SCOPE_P (TYPE_NAME (type)) + || (DECL_CONTEXT (TYPE_NAME (type)) + && TREE_CODE (DECL_CONTEXT (TYPE_NAME (type))) == NAMESPACE_DECL)) context_die = get_context_die (DECL_CONTEXT (TYPE_NAME (type))); TREE_ASM_WRITTEN (type) = 1;
At least the ICE we hit for the limbo node: if (DECL_P (node->created_for)) context = DECL_CONTEXT (node->created_for); else if (TYPE_P (node->created_for)) context = TYPE_CONTEXT (node->created_for); gcc_assert (context && (TREE_CODE (context) == FUNCTION_DECL || TREE_CODE (context) == NAMESPACE_DECL)); origin = lookup_decl_die (context); if (origin) add_child_die (origin, die); else add_child_die (comp_unit_die (), die); is odd, as the fallback for a non-existant context DIE is to attach the DIE to the comp-unit-die. So why not allow a comp-unit-die context in the first place? Thus, allow SCOPE_FILE_SCOPE_P limbo DIEs?
Without LTO we create the DIE for the TU level typedef via debug_hooks->type_decl, called from rest_of_decl_compilation which ultimately being dwarf2out_decl, sets the context_die to comp_unit_die () manually. As we do not gather or merge TYPE_DECLs with LTO we do not call rest_of_decl_compilation for TYPE_DECLs. So, with non-LTO we do not run into this seeming inconsistency in dwarf2out.c.
Author: rguenth Date: Fri Dec 16 14:31:14 2011 New Revision: 182401 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182401 Log: 2011-12-16 Richard Guenther <rguenther@suse.de> PR lto/51572 * dwarf2out.c (gen_type_die_with_usage): Use the context of the TYPE_DECL as well if it is file-scope. * gcc.dg/lto/pr51572-1_0.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/pr51572-1_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
Even with your patch (and also changing the similar occurrence a few lines below) and patch #1 from PR51573 libxul of Firefox still fails to build with the same ICE.
On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > --- Comment #10 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:40:28 UTC --- > Even with your patch (and also changing the similar occurrence > a few lines below) and patch #1 from PR51573 libxul of Firefox > still fails to build with the same ICE. Which ICE? The one from PR51572 or that from 51573?
(In reply to comment #11) > On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > > > --- Comment #10 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:40:28 UTC --- > > Even with your patch (and also changing the similar occurrence > > a few lines below) and patch #1 from PR51573 libxul of Firefox > > still fails to build with the same ICE. > > Which ICE? The one from PR51572 or that from 51573? This one from PR51572: ... At top level: lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22495
On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > --- Comment #12 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:45:32 UTC --- > (In reply to comment #11) > > On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > > > > > --- Comment #10 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:40:28 UTC --- > > > Even with your patch (and also changing the similar occurrence > > > a few lines below) and patch #1 from PR51573 libxul of Firefox > > > still fails to build with the same ICE. > > > > Which ICE? The one from PR51572 or that from 51573? > > This one from PR51572: > ... > At top level: > lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22495 I'd be interested in a testcase ... ;)
(In reply to comment #13) > On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > > > --- Comment #12 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:45:32 UTC --- > > (In reply to comment #11) > > > On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > > > > > > > --- Comment #10 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:40:28 UTC --- > > > > Even with your patch (and also changing the similar occurrence > > > > a few lines below) and patch #1 from PR51573 libxul of Firefox > > > > still fails to build with the same ICE. > > > > > > Which ICE? The one from PR51572 or that from 51573? > > > > This one from PR51572: > > ... > > At top level: > > lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22495 > > I'd be interested in a testcase ... ;) Will try ;-). But libxul is a huge beast to reduce.
On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > --- Comment #14 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:51:03 UTC --- > (In reply to comment #13) > > On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > > > > > --- Comment #12 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:45:32 UTC --- > > > (In reply to comment #11) > > > > On Fri, 16 Dec 2011, markus at trippelsdorf dot de wrote: > > > > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51572 > > > > > > > > > > --- Comment #10 from Markus Trippelsdorf <markus at trippelsdorf dot de> 2011-12-16 14:40:28 UTC --- > > > > > Even with your patch (and also changing the similar occurrence > > > > > a few lines below) and patch #1 from PR51573 libxul of Firefox > > > > > still fails to build with the same ICE. > > > > > > > > Which ICE? The one from PR51572 or that from 51573? > > > > > > This one from PR51572: > > > ... > > > At top level: > > > lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:22495 > > > > I'd be interested in a testcase ... ;) > > Will try ;-). > But libxul is a huge beast to reduce. Thanks, meanwhile I found that g++.dg/debug/pr45660.C ICEs the same way (after the patch for 51572). So I'll look at that now.
For g++.dg/debug/pr45660.C we have a limbo DIE for 'T' which has DECL_CONTEXT of the type 'S'. We create a DIE for 'S' when creating a DIE for the FUNCTION_DECL 'i' which we do when we output that function (via debug_hooks->function_decl) by emitting a DIE for its origin. Same without LTO, but with LTO we have dropped all non-FIELD_DECL members from 'S' so we do not output the TYPE_DECL when we have a context for it - so it gets on the limbo list.
It'll take me a while to do the necessary pre-reorg of streaming TREE_CHAIN for FIELD_DECLs -> next week.
Original profilebootstrap fail is fixed (from looking at gcc-testresults).
Author: rguenth Date: Mon Dec 19 13:37:06 2011 New Revision: 182479 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182479 Log: 2011-12-19 Richard Guenther <rguenther@suse.de> PR lto/51572 * tree.c (free_lang_data_in_type): Do not unlink TYPE_DECL from TYPE_FIELDS. (find_decls_types_r): Walk TYPE_DECLs in TYPE_FIELDS. * tree-streamer-out.c (write_ts_field_decl_tree_pointers): Do not stream TREE_CHAIN. (write_ts_type_non_common_tree_pointers): Stream TYPE_FIELDS using streamer_write_chain. * tree-streamer-in.c (lto_input_ts_field_decl_tree_pointers): Do not stream TREE_CHAIN. (lto_input_ts_type_non_common_tree_pointers): Stream TYPE_FIELDS using streamer_read_chain. * gimple-streamer-in.c (input_gimple_stmt): Skip non-FIELD_DECLs. * gimple.c (gimple_canonical_types_compatible_p): Properly handle trailing non-FIELD_DECLs in TYPE_FIELDS. * g++.dg/lto/pr51572-2_0.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/lto/pr51572-2_0.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-streamer-in.c trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c trunk/gcc/tree.c