The configure step of libgcc aborts with checking for suffix of object files... configure: error: in `/vol/gccsrc/obj/gcc-lto-20090127/11-gcc/sparc-sun-solaris2.11/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. config.log reveals configure:2590: checking for suffix of object files configure:2611: /vol/gccsrc/obj/gcc-lto-20090127/11-gcc/./gcc/xgcc -B/vol/gccsrc/obj/gcc-lto-20090127/11-gcc/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -c -g -O2 conftest.c >&5 conftest.c:16: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. configure:2614: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2627: error: in `/vol/gccsrc/obj/gcc-lto-20090127/11-gcc/sparc-sun-solaris2.11/libgcc': configure:2629: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. Running cc1 on this conftest.c gives % ./cc1 conftest.c main conftest.c:5: internal compiler error: in start_function, at c-decl.c:6225 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. The same problem happens on i386-pc-solaris2.10.
It turns out that there are two problems here: * If you invoke cc1 conftest.c (i.e. without -quiet), you get the ICE from the assertion failure in c-decl.c:6225: /* This is the earliest point at which we might know the assembler name of the function. Thus, if it's set before this, die horribly. */ gcc_assert (!DECL_ASSEMBLER_NAME_SET_P (decl1)); decl1 has an assembler_name of "main" at this point, which is due to this change in toplev.c (announce_function): @@ -419,10 +432,7 @@ announce_function (tree decl) { if (!quiet_flag) { - if (rtl_dump_and_exit) - fprintf (stderr, "%s ", IDENTIFIER_POINTER (DECL_NAME (decl))); - else - fprintf (stderr, " %s", lang_hooks.decl_printable_name (decl, 2)); + fprintf (stderr, "%s ", IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl))); fflush (stderr); pp_needs_newline (global_dc->printer) = true; diagnostic_set_last_function (global_dc, (diagnostic_info *) NULL); Unlike lang_hooks.decl_printable_name, decl_assembler_name sets assembler_name if unset, thus breaking the later assert. Since announce_functions gards this with !quiet_flag, it only breaks without that flag. * If instead on runs cc1 -g -quiet conftest.c (-g is necessary to trigger the bug which breaks configure, -quiet works around the first problem), on gets this instead. > ./cc1 -g -quiet conftest.c conftest.c:9: internal compiler error: Segmentation Fault Running cc1 under gdb reveals Program received signal SIGSEGV, Segmentation fault. 0x083fdd54 in get_personality_function (decl=0x0) at /vol/gcc/src/gcc-lto/gcc/expr.h:806 (gdb) where #0 0x083fdd54 in get_personality_function (decl=0x0) at /vol/gcc/src/gcc-lto/gcc/expr.h:806 #1 0x08404f08 in output_call_frame_info (for_eh=0) at /vol/gcc/src/gcc-lto/gcc/dwarf2out.c:2914 #2 0x08405fce in dwarf2out_frame_finish () at /vol/gcc/src/gcc-lto/gcc/dwarf2out.c:3351 #3 0x0899930a in compile_file () at /vol/gcc/src/gcc-lto/gcc/toplev.c:1023 #4 0x0899acc4 in do_compile () at /vol/gcc/src/gcc-lto/gcc/toplev.c:2220 #5 0x0899ad2b in toplev_main (argc=4, argv=0x80476cc) at /vol/gcc/src/gcc-lto/gcc/toplev.c:2252 #6 0x0821c2f9 in main (argc=4, argv=0x80476cc) at /vol/gcc/src/gcc-lto/gcc/main.c:35 I.e. get_personality_function is called with current_function_decl = NULL.
Rainer, can you please re-check this against the tip of the lto branch and report back? Thanks.
I just checked rev 149403, and while I had a couple of new problems building the lto branch (to be reported shortly), this particular problem is gone and (apart from libobjc) the default languages build. A testsuite run is in progress.
Fixed in (at least) r149403.