It seems that in r126296, tree-ssa-pre is using much more memory compiling libjava/interperter.cc than it did in r126044. I had to kill it after it was thrashing for more than 24 hours on my 128MB build machine. Configured thusly:../gcc/configure --with-arch=mips32 --with-float=soft --disable-java-awt --without-x --disable-tls --enable-__cxa_atexit --disable-jvmpi --disable-static --disable-libmudflap --enable-languages=c,c++,java At the time I killed it, it was using 342MB according to top. (gdb) bt #0 __libc_free (mem=0x58620b0) at malloc.c:3341 #1 0x00c94bec in htab_delete (htab=0x124ad08) at ../../gcc/libiberty/hashtab.c:396 #2 0x00a24340 in fini_pre () at ../../gcc/gcc/tree-ssa-pre.c:3929 #3 0x00a33040 in execute_pre (do_fre=0 '\0') at ../../gcc/gcc/tree-ssa-pre.c:4030 #4 0x00a33fb4 in do_pre () at ../../gcc/gcc/tree-ssa-pre.c:4038 #5 0x00861e98 in execute_one_pass (pass=0xddcef0) at ../../gcc/gcc/passes.c:1125 #6 0x008621c8 in execute_pass_list (pass=0xddcef0) at ../../gcc/gcc/passes.c:1178 #7 0x008621e4 in execute_pass_list (pass=0xddc3f0) at ../../gcc/gcc/passes.c:1179 #8 0x00976578 in tree_rest_of_compilation (fndecl=0x2b0c3600) at ../../gcc/gcc/tree-optimize.c:406 #9 0x00591188 in expand_body (fn=0x2b0c3600) at ../../gcc/gcc/cp/semantics.c:3136 #10 0x00b075e8 in cgraph_expand_function (node=0x2bd8aa00) at ../../gcc/gcc/cgraphunit.c:1073 #11 0x00b0a90c in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1142 #12 0x0050a7e8 in cp_write_global_declarations () at ../../gcc/gcc/cp/decl2.c:3310 #13 0x0090b470 in toplev_main (argc=<value optimized out>, argv=<value optimized out>) at ../../gcc/gcc/toplev.c:1064 #14 0x2ab96984 in __libc_start_main (main=0x63f420 <main>, argc=75, ubp_av=0x7fb04b64, init=0xcc5540 <__libc_csu_init>, fini=0x2aafd6b8 <_rtld_local>, rtld_fini=0x7fb054aa, stack_end=0x48)
Still happens in: revision 127079
seen on arm-linux & m68k-linux as well
CCing resident memory-hog bug killer.
haha, 300MB is nothing unusual. Btw, there's no libjava/interpreter.cc but libjava/interpret.cc. And that uses only ~200MB on x86_64.
Created attachment 14250 [details] testcase Btw, here's the (partly preprocessed) testcase I used.
As of r129803, I can bootstrap c,c++,java on my mipsel-linux build machine with 128MB RAM again. Although some files require more than 128MB of virtual memory, I have plenty of swap and the system does not thrash so horribly that it cannot complete a bootstrap. Unless there are protests, I will mark the bug as FIXED in a couple of days.
We no longer regress with respect to this testcase (bootstrapping on my small mipsel-linux system).