Attempting to build gcc-4.6 r162856 (head as of a few minutes ago) on i686-linux as a cross to armv5tel-linux-gnueabi fails with cc1 running out of memory: /tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/ -B/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/bin/ -B/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/lib/ -isystem /home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/include -isystem /home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc -I/tmp/gcc-4.6-r162856/libgcc -I/tmp/gcc-4.6-r162856/libgcc/. -I/tmp/gcc-4.6-r162856/libgcc/../gcc -I/tmp/gcc-4.6-r162856/libgcc/../include -DHAVE_CC_TLS -o _udivmoddi4.o -MT _udivmoddi4.o -MD -MP -MF _udivmoddi4.dep -DL_udivmoddi4 -c /tmp/gcc-4.6-r162856/libgcc/../gcc/libgcc2.c \ -fexceptions -fnon-call-exceptions cc1: out of memory allocating 171803424 bytes after a total of 46485504 bytes make[2]: *** [_udivmoddi4.o] Error 1 make[2]: Leaving directory `/tmp/objdir/armv5tel-unknown-linux-gnueabi/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/tmp/objdir' make: *** [all] Error 2 This happend twice in a row now. Repeating it a third time and watching the process with 'top' I see that cc1 grows to somewhere over 2.5 GB virtual before dying. The machine has 6 GB of RAM and 4 GB of swap, but it didn't start swapping before cc1 died. 4.6-20100731 (r162788) did not have this problem. Full configuration line: /tmp/gcc-4.6-r162856/configure --target=armv5tel-unknown-linux-gnueabi --with-arch=armv5te --with-tune=xscale --prefix=/home/mikpe/pkgs/linux-x86/cross-armv5tel --with-gmp=/home/mikpe/pkgs/linux-x86/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.8.2 --disable-plugin --disable-lto --disable-nls --disable-shared --disable-libmudflap --disable-multilib --enable-threads=posix --enable-checking=release --enable-languages=c
Can you check where it sits eating all emmory?
Attaching gdb after cc1 just passed 2.5 G virtual: 0x080c0c93 in pool_alloc (pool=0xa45d708) at /tmp/gcc-4.6-r162856/gcc/alloc-pool.c:252 252 { Missing separate debuginfos, use: debuginfo-install glibc-2.10.2-1.i686 (gdb) bt #0 0x080c0c93 in pool_alloc (pool=0xa45d708) at /tmp/gcc-4.6-r162856/gcc/alloc-pool.c:252 #1 0x0812091e in df_ref_create_structure (cl=DF_REF_REGULAR, collection_rec=<value optimized out>, reg=0xb757a1c0, loc=0xb734d814, bb=0xb7534400, info=0xa46b930, ref_type=DF_REF_REG_MEM_STORE, ref_flags=0, width=-1, offset=-1, mode=VOIDmode) at /tmp/gcc-4.6-r162856/gcc/df-scan.c:2802 #2 0x08120a8c in df_ref_record (cl=<value optimized out>, collection_rec=<value optimized out>, reg=<value optimized out>, loc=0xb734d814, bb=0xb7534400, insn_info=0xa46b930, ref_type=DF_REF_REG_MEM_STORE, ref_flags=0, width=-1, offset=-1, mode=VOIDmode) at /tmp/gcc-4.6-r162856/gcc/df-scan.c:2928 #3 0x081210d7 in df_uses_record (cl=<value optimized out>, collection_rec=<value optimized out>, loc=<value optimized out>, ref_type=DF_REF_REG_MEM_STORE, bb=0xb7534400, insn_info=0xa46b930, flags=0, width=-1, offset=-1, mode=VOIDmode) at /tmp/gcc-4.6-r162856/gcc/df-scan.c:3159 #4 0x081219d7 in df_insn_refs_collect (collection_rec=<value optimized out>, bb=<value optimized out>, insn_info=0x1f68fb8) at /tmp/gcc-4.6-r162856/gcc/df-scan.c:3571 #5 0x08121f3a in df_insn_refs_verify (collection_rec=0xbfb95d50, bb=0x7, insn=<value optimized out>, abort_if_fail=0 '\0') at /tmp/gcc-4.6-r162856/gcc/df-scan.c:4466 #6 0x081222b6 in df_insn_rescan (insn=0x13e97828) at /tmp/gcc-4.6-r162856/gcc/df-scan.c:1260 #7 0x0826d4f3 in peep2_update_life (prev=<value optimized out>, last=<value optimized out>, match_len=<value optimized out>, bb=<value optimized out>) at /tmp/gcc-4.6-r162856/gcc/recog.c:3313 #8 peephole2_optimize (prev=<value optimized out>, last=<value optimized out>, match_len=<value optimized out>, bb=<value optimized out>) at /tmp/gcc-4.6-r162856/gcc/recog.c:3441 #9 rest_of_handle_peephole2 (prev=<value optimized out>, last=<value optimized out>, match_len=<value optimized out>, bb=<value optimized out>) at /tmp/gcc-4.6-r162856/gcc/recog.c:3619 #10 0x082534cb in execute_one_pass (pass=0x8863640) at /tmp/gcc-4.6-r162856/gcc/passes.c:1564 #11 0x0825374d in execute_pass_list (pass=0x8863640) at /tmp/gcc-4.6-r162856/gcc/passes.c:1619 #12 0x08253760 in execute_pass_list (pass=0x88634e0) at /tmp/gcc-4.6-r162856/gcc/passes.c:1620 #13 0x08253760 in execute_pass_list (pass=0x88634a0) at /tmp/gcc-4.6-r162856/gcc/passes.c:1620 #14 0x0831f87a in tree_rest_of_compilation (fndecl=0xb74dc400) at /tmp/gcc-4.6-r162856/gcc/tree-optimize.c:452 #15 0x0844c02f in cgraph_expand_function (node=<value optimized out>) at /tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1643 #16 0x0844d201 in cgraph_expand_all_functions () at /tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1722 #17 cgraph_optimize () at /tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1978 #18 0x0844da15 in cgraph_finalize_compilation_unit () at /tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1185 #19 0x08056f9c in c_write_global_declarations () at /tmp/gcc-4.6-r162856/gcc/c-decl.c:9698 #20 0x082e2324 in compile_file () at /tmp/gcc-4.6-r162856/gcc/toplev.c:957 #21 do_compile () at /tmp/gcc-4.6-r162856/gcc/toplev.c:2295 #22 toplev_main () at /tmp/gcc-4.6-r162856/gcc/toplev.c:2336 #23 0x080baeeb in main (argc=62, argv=0xbfb96134) at /tmp/gcc-4.6-r162856/gcc/main.c:36
It's caused by r162815: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00026.html The build failure still occurs with r162878.
I'm not seeing this with my ARM cross-compilers. Can you attach a .i file?
Created attachment 21398 [details] preprocessed source for _udivmoddi4 In non-parallel builds _udivmoddi4 is always the first module to make cc1 run out of memory. I get the error on both i686 and x86_64 hosts, and with both gcc-4.4.4 and gcc-4.3.5 as bootstrap compilers (only tried 4.3.5 on i686 though). I did use --with-arch=armv5te --with-tune=xscale when configuring my compiler, which may be relevant as it changes instruction selection defaults.
Subject: Bug 45177 Author: bernds Date: Tue Aug 10 18:45:10 2010 New Revision: 163077 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163077 Log: PR bootstrap/45177 * config/arm/arm.c (multiple_operation_profitable_p): Move xscale test here from arm_gen_load_multiple_1. (arm_gen_load_multiple_1, arm_gen_store_multiple_1): Use multiple_operation_profitable_p. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
Is this now fixed ?
Yes.