This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug lto/48200] linking shared library with LTO results in different exported symbols
- 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: Thu, 03 May 2018 10:08:30 +0000
- Subject: [Bug lto/48200] linking shared library with LTO results in different exported symbols
- Auto-submitted: auto-generated
- References: <bug-48200-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to Jan Hubicka from comment #13)
> > Concerning comment #11, if you have toplevel asms you need to disable LTO
> > for that unit, as there is no way to tell for gcc what the asm statement is
> > doing. Perhaps attribute would be better way to do this?
>
> Well then this is PR 57703. Should we mark duplicate? :(
I think the bug is sufficiently different and should have different
workarounds.
We might want to add a function attribute to allow to specify symver, so like
int pci_fill_info_v31(struct pci_dev *d, int flags)
__attribute__((alias("pci_fill_info"), symver("@LIBPCI_3.0"));
or similar (combine alias and symver as symver_alias?). Or simply
recognize @ in alias.