When the graphite useflag is set, the ebuild for >=gcc-4.4.x wastes 50% of cpu cycles with useless polling of the .ipc_in FIFO. This has nothing to do with gcc itself, or whether gcc was built with graphite enabled. I think maybe it's a bug in toolchain.eclass? To reproduce: set the graphite useflag and emerge any >=gcc-4.4.x. You should see the 'emerge' process hogging half the cpu constantly during the emerge. Run strace on the 'emerge' process and you should see it doing nothing but polling /dev/ptmx and the '.ipc_in' FIFO.
Sorry, forgot to mention I'm running portage-2.1.10.3 on ~amd64 and ~x86 and see the same problem on both machines.
The symptom seems similar to bug 339976. I doubt that it's any fault of the ebuild or eclass, though it's interesting that you're observing a correlation.
I'm happy to report that I'm now compiling gcc-4.5.3-r2/graphite on x86 and amd64 with normal speed -- in fact the build seems supersonic compared to the last time I built gcc. I guess this bug can be closed as FIXED, though I don't know who or what fixed it :)
Thanks for reporting. It's the same as bug 401919, which is fixed in 2.1.10.46 and 2.2.0_alpha86.
*** This bug has been marked as a duplicate of bug 401919 ***
