> On Tue, 4 Mar 2014, Jan Hubicka wrote: > > > > > > > The following patch addresses the common (?) issue of people > > > omitting -flto from the linker command-line which gets more > > > severe with GCC 4.9 where slim LTO objects are emitted by > > > default. The patch simply _always_ arranges for the linker > > > plugin to be used, so if there are any (slim) LTO objects > > > on the link LTO will be done on them. Similarly the > > > non-linker-plugin path in collect2 is adjusted. > > > > > > You can still disable this by specifying -fno-lto on the > > > linker command-line. > > > > > > One side-effect of enabling the linker-plugin by default > > > (for HAVE_LTO_PLUGIN == 2) is that collect2 will then > > > use the configured plugin ld rather than the default ld. > > > Not sure if that is desired. > > > > > > Comments? > > > > I like it; it was on my TODO list, but I was only worried about > > --with-plugin-ld and did not find time, yet, to look into the consequences. > > These days, I do not think we need to worry much aboud --with-plugin-ld. > > Yeah, I think we should eventually remove that capability. > > Now as of the two patches (compute a default link-time optimization > level and this patch, make considering LTO at link-time the default), > they only make sense together (at least the default opt level at > link-time doesn't improve real-world situations without also considering > all links to be possibly -flto). > > So the question remains if we want to have both patches at this > stage or if we want to wait with them for 4.10 (we do have the > user-visible change of slim-lto objects by default with 4.9 > already).
I think it makes things easier, so I would like to see this in 4.9 Honza
