Description of problem: GCC 4.4.1-10 has the backported var-tracking-assignment from GCC 4.5; this breaks the PPC build of LLVM 2.6 (but works fine on i686 and x86_64) Version-Release number of selected component (if applicable): gcc-c++-4.4.1-10.ppc How reproducible: Always Steps to Reproduce: 1. checkout Fedora's LLVM specs 2. disable workaround in 2.6-0.5.pre1 3. attempt a ppc build Actual results: Build fails: http://koji.fedoraproject.org/koji/buildinfo?buildID=131130 Expected results: Build should pass, as it does in llvm-2.6-0.3.pre1 built with a previous GCC release Additional info:
Created attachment 360465 [details] SPUISelDAGToDAG.ii.bz2 Reproduceable even on x86_64-linux -> powerpc64-linux cross. ./cc1plus -m32 -g -O2 SPUISelDAGToDAG.ii eats lots of memory in vartrack pass, I've stopped it after it ate 31GB on my box. I guess we really need to put some upper bounds on number of basic blocks/number of tracked VALUEs at which point we restart with ignoring DEBUG_INSNs. Select_SPUISD_MUL64_MARKER_i64 has just 5 basic blocks though, so it is quite different from the few extreme PRs from cc1files VARIOUS. There are hundreds of thousands of NOTE_VAR_INSN_LOCATION though. The code is completely insane, calling a function with 1371 arguments, out of which 685 are classes passed by value mustn't be done by very smart programmers, that said var-tracking shouldn't require so much memory on it and just give up trying making the code debuggable.
In *.compgotos the function in question has 3434 DEBUG_INSNs and 4349 other insns (just 4 calls and 3 jumps).
That Emit_201 bug just got filed by Chris Lattner upstream, so hopefully this will be addressed soon. I doubt it'd be for 2.6, though, it's not listed as a blocker. http://llvm.org/bugs/show_bug.cgi?id=4946
Self-contained testcase: ./cc1plus -g -O2 -m32: struct A { int a; A() : a(0) {} A(int x) : a(x) {} }; struct B { A a; void *b; B() : a(0), b(0) {} B(int x) : a(x), b(0) {} B(A x) : a(x), b(0) {} }; #define X10 X1 X1 X1 X1 X1 X1 X1 X1 X1 X1 #define X100 X10 X10 X10 X10 X10 X10 X10 X10 X10 X10 #define X685 X100 X100 X100 X100 X100 X100 X10 X10 X10 X10 X10 X10 X10 X10 X1 X1 X1 X1 X1 extern void insane ( #define X1 B, X685 #undef X1 int ); int not_sane () { insane ( #define X1 6, X685 #undef X1 7); return 0; } (strangely for -m64 it doesn't eat significant amount of memory).
Created attachment 360697 [details] Q2.C Actually, it didn't reproduce this, it ate 700MB of RAM, but didn't start eating unbounded amounts of RAM quickly. But this one reproduces it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41343 might be the same problem, and I posted over there a patch that alleviates the problem reported here. It still takes a lot of memory and takes too long to compile, but memory consuption doesn't exactly explode, as garbage generated during expansion of location expressions is now recycled quickly.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I believe this should be fixed now in recent gccs (like 4.4.3-18).