Launchpad has imported 9 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45177.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers. ------------------------------------------------------------------------ On 2010-08-04T09:14:55+00:00 Mikpelinux wrote: 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 Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/0 ------------------------------------------------------------------------ On 2010-08-04T09:19:13+00:00 Rguenth wrote: Can you check where it sits eating all emmory? Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/1 ------------------------------------------------------------------------ On 2010-08-04T10:01:37+00:00 Mikpelinux wrote: 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 Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/2 ------------------------------------------------------------------------ On 2010-08-04T20:06:41+00:00 Mikpelinux wrote: It's caused by r162815: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00026.html The build failure still occurs with r162878. Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/3 ------------------------------------------------------------------------ On 2010-08-04T21:16:31+00:00 Bernds-gcc wrote: I'm not seeing this with my ARM cross-compilers. Can you attach a .i file? Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/4 ------------------------------------------------------------------------ On 2010-08-04T22:15:50+00:00 Mikpelinux wrote: Created attachment 21398 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. Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/5 ------------------------------------------------------------------------ On 2010-08-10T18:45:42+00:00 Bernds-gcc wrote: 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 Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/6 ------------------------------------------------------------------------ On 2010-08-10T22:17:03+00:00 Ramana-gcc wrote: Is this now fixed ? Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/7 ------------------------------------------------------------------------ On 2010-08-10T22:31:24+00:00 Bernds-gcc wrote: Yes. Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/721021/comments/8 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/721021 Title: GCC ICE on arm/xscale To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/721021/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
