There seems to be some kind of a bug in gcc-4.4.2-4.fc12 that makes compilation ridiculously slow. The srpm http://theory.physics.helsinki.fi/~jzlehtol/rpms/psi-3.4.0-3.fc12.src.rpm has been building in koji http://koji.fedoraproject.org/koji/taskinfo?taskID=1768528 for 21 hours now. On EPEL 5 (gcc-4.1.2-46.el5) the same srpm builds with the same options within a half hour or so. The problems seem to come out in the compilation of the libint library, that is machine generated.
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 have the same problem with bug 539222 and the review request bug 537363 . Both compile fine on F-11 but take forever on F-12. For the latter one I figured that the -O2 flag is what makes the compilations stall. I take -O2 out and the compilation time drops from days to seconds. Will this be fixed soon?
Please try http://kojipkgs.fedoraproject.org/packages/gcc/4.4.2/24.fc12/
Has been compiling for almost 10 hours, so there doesn't seem to be any improvement.
Can you please provide preprocessed source for the file on which it takes so long, and all gcc options passed to it? FYI, 4.4.2-24.fc12 isn't in dist-12-build nor dist-f13-build, so if you are just trying to build it in koji, it will use an older gcc.
Created attachment 383564 [details] Preprocessed source Preprocessed source file.
Attachment in comment #6 compiles on my desktop in 40 us with plain "g++ -c", in 19 s with "g++ -O2 -c", but with the standard flags "g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic" it takes a *really* long time. (In reply to comment #5) > FYI, 4.4.2-24.fc12 isn't in dist-12-build nor dist-f13-build, so if you are > just trying to build it in koji, it will use an older gcc. Yes, that's why I used mock with a local repo providing the new gcc packages that were picked up for the build.
I guess I'll resurrect the gcc44-max-vartrack-size.patch, but this time with a 50000000 default instead of 5000000. That way it shouldn't trigger on reasonably sized testcases and will only trigger on these monsters.
gcc-4.4.2-4.fc12 with the above mentioned default vartrack size limit has been released as errata.