I got several ICEs during a linux kernel whopr build, here's one of them. gcc46 -nostdlib -fwhopr -r -o net/ipv4/built-in.o net/ipv4/route.o net/ipv4/inetpeer.o net/ipv4/protocol.o net/ipv4/ip_input.o net/ipv4/ip_fragment.o net/ipv4/ip_forward.o net/ipv4/ip_options.o net/ipv4/ip_output.o net/ipv4/ip_sockglue.o net/ipv4/inet_hashtables.o net/ipv4/inet_timewait_sock.o net/ipv4/inet_connection_sock.o net/ipv4/tcp.o net/ipv4/tcp_input.o net/ipv4/tcp_output.o net/ipv4/tcp_timer.o net/ipv4/tcp_ipv4.o net/ipv4/tcp_minisocks.o net/ipv4/tcp_cong.o net/ipv4/datagram.o net/ipv4/raw.o net/ipv4/udp.o net/ipv4/udplite.o net/ipv4/arp.o net/ipv4/icmp.o net/ipv4/devinet.o net/ipv4/af_inet.o net/ipv4/igmp.o net/ipv4/fib_frontend.o net/ipv4/fib_semantics.o net/ipv4/inet_fragment.o net/ipv4/sysctl_net_ipv4.o net/ipv4/fib_trie.o net/ipv4/proc.o net/ipv4/inet_lro.o net/ipv4/tunnel4.o net/ipv4/ipconfig.o net/ipv4/inet_diag.o net/ipv4/tcp_diag.o net/ipv4/tcp_cubic.o In file included from :377:0: net/ipv4/igmp.c: In function 'igmp_mcf_get_next': net/ipv4/igmp.c:2528:27: 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. lto-wrapper: gcc46 returned 1 exit status collect2: lto-wrapper returned 1 exit status Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/pkg/gcc-4.6-100607 --enable-checking=release --enable-languages=c,c++ --disable-nls --enable-lto --enable-gold --with-plugin-ld=/usr/local/bin/gold --with-elf-include=/usr/include/libelf Thread model: posix gcc version 4.6.0 20100607 (experimental) (GCC)
Ok unable to attach and I've been told reporting LTO bugs requires some magic voodoo incarnations first. If it helps here's the gdb information of the crash: (gdb) pt var <error_mark 0x1200022> (gdb) bt #0 var_map_base_init (map=0x1102b00) at ../../gcc/gcc/tree-ssa-live.c:87 #1 0x00000000007248fb in coalesce_ssa_name () at ../../gcc/gcc/tree-ssa-coalesce.c:1405 #2 0x00000000006fd30f in rewrite_out_of_ssa (sa=0x10540a0) at ../../gcc/gcc/tree-outof-ssa.c:909 #3 0x00000000004d46d8 in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:3742 #4 0x000000000062afd1 in execute_one_pass (pass=0xf503e0) at ../../gcc/gcc/passes.c:1576 #5 0x0000000000fe28e0 in ?? () #6 0x010000000062aeb4 in ?? () #7 0x0000000000f503e0 in ?? () #8 0x0000000000000000 in ?? () (gdb) Somehow "error_mark" got in there.
The object files are at http://halobates.de/whopr-ice.tar.bz2
Did you reduce the number of object files already? Note that you are linking without optimization (and you probably built the .o files with optimization?) So this might be a duplicate of PR41159. Can you put output of adding -v to one of the .o file compiles? Can you put preprocessed source of all .o file sources that are required to reproduce the bug somewhere? Thx.
I was told that the whopr link step would inherit the optimization flags from the build step. Is that not true? Here's a reduced test case with only a single input file (reduced too) gcc46 -O2 -fwhopr -c igmp.mini.i gcc46 -r -fwhopr igmp.mini.o
Created attachment 20875 [details] reduced input file
(In reply to comment #4) > I was told that the whopr link step would inherit the optimization > flags from the build step. Is that not true? That's not true. > Here's a reduced test case with only a single input file (reduced too) > > gcc46 -O2 -fwhopr -c igmp.mini.i > gcc46 -r -fwhopr igmp.mini.o Thanks. Confirmed (also with -flto). Program received signal SIGSEGV, Segmentation fault. 0x0000000000a196e8 in var_map_base_init (map=0x16479c0) at /space/rguenther/src/svn/trunk/gcc/tree-ssa-live.c:87 87 if (!ann->base_var_processed) (gdb) p ann $1 = (var_ann_t) 0x0 probably not too hard to track down. The decl is a PARM_DECL and not registered with referenced vars.
Actually - we seem to get IPA SRA parm repacements done but the original parameter SSA names are not released. (gdb) call debug_function (cfun->decl, 0) igmp_mc_get_next (<unnamed type> * ISRA.14, struct ip_mc_list * ISRA.15) { struct ip_mc_list * im; (gdb) call debug_generic_expr ($5) im_1 Martin - can you have a look?
CC'ing martin even.
Unfortunate. Fixing that in the makefiles would be major effort for all the -f and -m flags, which sometimes vary by target. I thought LTO was designed to minimize makefile changes?
The tree input that leads to the NULL annotation is a "error_mark"
(In reply to comment #10) > The tree input that leads to the NULL annotation is a "error_mark" Not for me.
(In reply to comment #9) > Unfortunate. Fixing that in the makefiles would be major effort for all the -f > and -m flags, which sometimes vary by target. > > I thought LTO was designed to minimize makefile changes? Yes. But you want to be able to have different optimizations at compile/link time. Also we would need to start on how to automagically merge different settings at compile-time ... Well - option handling is still an awkward area.
What happens then when some files need different options that other files? This sounds more and more like a showstopper if you're right. I was not prepared to redesign the Makefiles
I found this code in lto.c which seems to disagree: /* Read the options saved from each file in the command line. Called from lang_hooks.post_options which is called by process_options right before all the options are used to initialize the compiler. This assumes that decode_options has already run, so the num_in_fnames and in_fnames are properly set. Note that this assumes that all the files had been compiled with the same options, which is not a good assumption. In general, options ought to be read from all the files in the set and merged. However, it is still unclear what the merge rules should be. */ void lto_read_all_file_options (void) Still remains to be seen if it DTRT though (e.g. for -pg vs no -pg)
Ok seems it does not do what I want: FIXME lto. Currently the scheme is limited in that only the options saved on the first object file (f1.o) are read back during the link step. This means that the options used to compile f1.o will be applied to ALL the object files in the final link step. More work needs to be done to implement a merging and validation mechanism, as this will not be enough for all cases. */ Anyways OT for this bug, maybe needs a new one?
I reduced another of my ICEs from this build and it's in the same place. (gdb) bt #0 var_map_base_init (map=0x10abe60) at ../../gcc/gcc/tree-ssa-live.c:87 #1 0x00000000007248fb in coalesce_ssa_name () at ../../gcc/gcc/tree-ssa-coalesce.c:1405 ...
Created attachment 20882 [details] other test case
When I tried the LTO step in any of the two testcases I got: jamborm@tuc:~/gcc/mine/test/pr44464$ ~/gcc/inst/mine/bin/gcc -r -fwhopr igmp.mini.o /usr/bin/ld: cannot find -lgcc_s collect2: ld returned 1 exit status What am I doing wrong? (And what does the -r switch, I can't find it in the documentation)
Sorry you need -nostdlib too (forgot that) -r is immediate linking
Subject: Bug 44464 Author: jamborm Date: Tue Jun 15 11:09:12 2010 New Revision: 160777 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160777 Log: 2010-06-15 Martin Jambor <mjambor@suse.cz> PR lto/44464 * tree-sra.c (replace_removed_params_ssa_names): Call release_ssa_name on the newly dead SSA name. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-sra.c
Subject: Bug 44464 Author: jamborm Date: Wed Jun 16 17:01:06 2010 New Revision: 160852 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160852 Log: 2010-06-15 Martin Jambor <mjambor@suse.cz> PR lto/44464 * tree-sra.c (replace_removed_params_ssa_names): Call release_ssa_name on the newly dead SSA name. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/tree-sra.c
This is now fixed on both the trunk and the 4.5 branch.