I've just started playing with graphite. With e.g. mplayer and SDL, it will try to use all available memory, bringing the PC to its knees with disk thrashing. To prevent that, use ulimit, e.g. with 4gb RAM:

Code:

ulimit -v 1200000

I've put that in my root's ~/.bashrc, to make the compilation fail instead of pinching all RAM.

The problem with these are not built failures but runtime failures. Since 4.8.0, I disabled graphite since it has broken too many things (accidental crashes, strange behavior etc. pp); in earlier versions of gcc there were only occasional build failures with graphite but since 4.8.0 it has become practically unusable (at least world-wide).
In contrast with lto: I do not remember any package which built with LTO but produced runtime failures. Of course, many packages won't build with LTO.

sys-devel/gcc no-graphite.conf # looks like causes some apps to crash (qtcreator for example). have to make more tests.

Ah, I see: I had compiled gcc-4.8.{0,1}* with graphite, of course. Maybe this is the reason for my many problems with graphite. On the other hand, it would be a strange accident that using gcc compiled with graphite just has problems for compiling with graphite. But who knows: Maybe the cause is that something in graphite is not reentrant or thread-safe and using graphite with a graphite-compiled gcc just forces such a behavior?

sys-devel/gcc no-graphite.conf # looks like causes some apps to crash (qtcreator for example). have to make more tests.

Ah, I see: I had compiled gcc-4.8.{0,1}* with graphite, of course. Maybe this is the reason for my many problems with graphite. On the other hand, it would be a strange accident that using gcc compiled with graphite just has problems for compiling with graphite. But who knows: Maybe the cause is that something in graphite is not reentrant or thread-safe and using graphite with a graphite-compiled gcc just forces such a behavior?

As I said, the problem is not building it but too many runtime failures: The behaviour of vim (saving broken data after editing which obviously also other have experienced) is a typical example; since avoiding graphite solves these issues, it seems that this is not a bug of vim but actually of gcc w/graphite.