[Bug lto/47247] New: Linker plugin specification makes it difficult to handle COMDATs

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247

           Summary: Linker plugin specification makes it difficult to
                    handle COMDATs
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hubicka@gcc.gnu.org


Current linker plugin specification has problem with COMDAT.  When COMDAT
fnuction is put into symbol table and is used, it gets resolved as PREVAILING.
This imply that it must be output in the final binary.

This is often suboptimal because inlining often eliminate need for the out of
line copy of COMDAT. GCC works around by not putting COMDAT symbols into symbol
table. This leads to posibility that both LTO and non-LTO objects will define
variant of the COMDAT function and that GCC will bring the LTO one static and
thus two copies of COMDAT will be present. For this reason GCC will not do this
for COMDAT function that is not virtual and has address taken.

This trick works well in most cases, but leads i.e. to undefined symbols when
Mozilla is built with LTO and -fprofile-generate
https://bugzilla.mozilla.org/show_bug.cgi?id=624385

this is because GCC no longer optimize out some functions from unused header.
This is because indirect call profiling takes their address and forces them to
stay in the program.

In longer therm we really need better solution for this.