This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/53572] Some public symbols don't get to serialized LTO
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 04 Jun 2012 14:38:06 +0000
- Subject: [Bug lto/53572] Some public symbols don't get to serialized LTO
- Auto-submitted: auto-generated
- References: <bug-53572-4@http.gcc.gnu.org/bugzilla/>
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