http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
Bug ID: 59893 Summary: Use LTO for libgcc.a, libstdc++.a, etc Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: build, lto Severity: enhancement Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Hello, LTO is not really a brand new, experimental and exotic option anymore. I believe that by default, on systems that support it, we should build the static target libraries that are part of gcc with -flto (and obviously -ffat-lto-objects). This should have no impact on people not using LTO (well, slightly longer bootstrap and a little bit of hard drive wasted), and people using LTO actually expect it to apply to libstdc++ when building statically. This should "solve" PR 59048 for instance where a simple std::string function is hidden in libstdc++ and we thus miss an optimization. Assuming it works, it could also help to have new/delete inlined from libsupc++, so the middle-end optimizations on malloc/free have a chance to apply. It may be as easy as adding the flags to C(XX)FLAGS_FOR_TARGET or it may be much harder (I probably should have tried it before filing this PR), but it seems we'll have to get there eventually. This is quite different from bootstrap-lto as it applies to the target, not the host.