[Bug lto/53572] Some public symbols don't get to serialized LTO

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

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

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> 2012-06-04 19:52:51 UTC ---
> > !node->symbol.used_from_other_partition
> > -         && (DECL_COMDAT (node->symbol.decl)
> > +         && ((DECL_COMDAT (node->symbol.decl)
> > +              && symtab_used_from_object_file_p ((symtab_node) node))
> 
> && !symtab_used_from_object_file_p

Ah, yes. Sorry.
> 
> I suppose.  I would have expected used_from_other_partition to be true

Well, used_from_other_partition reffers to IR partitions, not "other uses".
I would not mix them unless we need so. There are some differences - like
symbols from other partitions can be local and can use custom calling
conventions.
Symbols used form asm can't.

> > But perhaps it is now resonable to expect V2 linker API even for GCC 4.7 based
> > setups for sane LTO with C++?  We already mention in release notes that V1 API
> > is bad idea...
> 
> Well, sure - assuming that we have a V2 capable linker is ok I guess.  In the
> end we should simply annotate the resolution file with the linker capability,
> thus extend the file-format to include a one-line header with a version.

As I tried to explain on IRC, this won't help since V1/V2 API differs already
on compile time when we don't have linker plugin and have no clue what version
of API will be used at linktime.
It is possible to teach lto-plugin to do the hack instead of doing it in 
lto-streamer-out.c if we really want sane support for V1 API.

Concerning the problem in this PR, i guess we probably should give up handling
this sanely in V1 API: we already hide COMDAT vtables and type descriptions
should be harmless/dropped by the linker eventually.

Honza