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

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-04 14:38:06 UTC ---
(In reply to comment #3)
> I do not have linker plugin enabled setup handy at the moment, but the
> following patch should fix it:
> Index: cgraph.h
> ===================================================================
> --- cgraph.h    (revision 188138)
> +++ cgraph.h    (working copy)
> @@ -1126,7 +1126,8 @@ varpool_can_remove_if_no_refs (struct va
>    if (DECL_EXTERNAL (node->symbol.decl))
>      return true;
>    return (!node->symbol.force_output &&
> !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

I suppose.  I would have expected used_from_other_partition to be true
in this case.  Also the 4.7 branch looks suspiciously different from
this, referencing flag_toplevel_reorder ...

The adjusted as above patch works on trunk though.

But I really would say "object file"s are also another "partition".

>               || !node->symbol.externally_visible
>               || DECL_HAS_VALUE_EXPR_P (node->symbol.decl)));
>  }
> 
> I am testing this patch for mainline.
> As discussed on IRC, this patch can have negative effect on V1 linker API
> setups: here all comdats appears to be externally visible and thus they will be
> forced to output.

If as comdat the linker should eliminate them.

> 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.

Richard.

> Honza