I haven't tried enabling LTO for quite a while, but just ran across this new post on LWN. Does this possibly mean that LTO optimization is getting closer to being usable?

Any feedback (pro or con) on what all this means? I have a rarely used (but kept up-to-date) Gentoo "testing" partition on a spare hard drive, and might be tempted to give LTO another try if I can find some spare time.

Reading some of their comments quickly convinced me that I knew even less about this stuff than I thought I did, which I realized was not very much in the first place.

Obviously, my lack of expertise would not allow me to be of any help. Guess I'll have to wait until gcc-4.8 makes it into Gentoo ~Arch, and try enabling LTO then. One would think that the gcc dev's goal is to eventually enable LTO as the default, since they keep mentioning it in each release version's documentation.

@ssam,
Thanks for the reply- I had looked at this before, but I think your comments have helped me begin to understand it a little more clearly.

@xming,
Could you post a few more details, please? Do you mean you only compiled your kernel with LTO enabled (and are using the kolivas BFS scheduler), or are you also having decent success with doing a complete emerge -e @system and/or @world?

Or, if you're only using an LTO compiled kernel, is there any noticable performance improvement in other non-LTO compile applications at runtime?

I am running 3.5.2 with LTO and bfs + some other patches. As for packages I don't have lto enabled for all, just some. I can't say if it's faster as I haven't run any benchmarks. All I can say it's rather stable (no issues so far) and it feels a bit smoother._________________http://wojia.be

IIRC, a while back there was a forum thread that started listing packages that could be compiled with LTO enabled, but I've lost track of it.

Anyone think trying an emerge -e @system is worth a shot (with kernel 3.5.2 and gcc-4.7.1) and seeing what fails, considering there might have been some progress in the last year or two since I last attempted this?

I was just about to give a try, so, generally speaking, I can do this. The only thing is I'm using just stock 3.5.2 kernel instead of Gentoo's. I thing that other CFLAGS (besides -flto) would have great impact or successfull compilation. So below is mine:

IIRC, a while back there was a forum thread that started listing packages that could be compiled with LTO enabled, but I've lost track of it.

Anyone think trying an emerge -e @system is worth a shot (with kernel 3.5.2 and gcc-4.7.1) and seeing what fails, considering there might have been some progress in the last year or two since I last attempted this?

Yes I am using /etc/portage/env/, I was having more packages built with gcc 4.6.x than 4.7, so I had to dial back the lto usage._________________http://wojia.be

I'm running 3.6-lto on two different x86_64 machines (thinkpad x201+router/firewall) and it's very stable so far. I'll do some few benchmarks soon, network latency seems to have been significantly improved.

The system is rock stable. I haven't had any problem regarding lto, other than not compile with lto (except glib, but it was a know issue). Binaries are smaller. Is it faster ? Well, I don't know. It's not noticeable. I have an CPU still powerful and my system is on an SSD, so... it's hard to notice a speed improvement without benchmarks._________________Sorry for my English. I'm still learning this language.

@costel78: To me it would be worth knowing what version of virtualbox you managed to build with gcc-4.7.1 - by chance, does dev86 build successfully too?_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

The list of packages which do not compile with -lto is not really shrinking. In fact, with newer versions of packages and gcc-4.7.1, I even had to add some. Here is my current list for filtering -flto and related flags:

My experience is that everything which compiles with LTO also runs without problems. However, for many packages, I get warnings related to -D_FORTIFY_SOURCE=2 (e.g. warnings about possibly transposed arguments of memset) which do not occur without flto and which are hard to reproduce (e.g. I realized that they depend on the order of includes of standard libraries). I have not tried vanilla gcc, i.e. it could be that this problem is only related with gentoo's patches concerning D_FORTIFY_SOURCE.

Unfortunately I'm on no-multilib profile so I'm able to use just virtualbox-bin, but I just tested it and sys-devel/dev86-0.16.18 emerge was successfully._________________Sorry for my English. I'm still learning this language.

Link-time optimization does not work well with generation of debugging information. Combining -flto with -g is currently experimental and expected to produce wrong results.

Probably none. I would guess the "expected to produce wrong results" refer to broken debugging information. However, even if it does not: I doubt that many packages add -g by themselves to CFLAGS, and AFAIK neither do gentoo's gcc patches nor portage if used in "normal" mode.

Link-time optimization does not work well with generation of debugging information. Combining -flto with -g is currently experimental and expected to produce wrong results.

Probably none. I would guess the "expected to produce wrong results" refer to broken debugging information. However, even if it does not: I doubt that many packages add -g by themselves to CFLAGS, and AFAIK neither do gentoo's gcc patches nor portage if used in "normal" mode.

I have not been able to figure this out. May be u can help. Parts of firefox build are done using "-g". And those parts fail to build when CFLAGS/CXXFLAGS have -flto also. Are you able to build firefox with -flto? I have the "custom-cflags custom-optimization" USE flags for firefox and use package.env to set lto.

Unfortunately I'm on no-multilib profile so I'm able to use just virtualbox-bin, but I just tested it and sys-devel/dev86-0.16.18 emerge was successfully.

kthx, I've also built gcc-4.7.1 now and verified that there seems to be more than less breakage with current 4.7.2_pre9999 - virtualbox, dev86 won't build with the latter. But there's another thread for gcc-4.7_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic