[Bug other/59893] New: Use LTO for libgcc.a, libstdc++.a, etc

["glisse at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.