This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 1 Feb 2012 14:56:29 +0100
- Subject: Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
- References: <4F25DF6A.email@example.com> <20120130142341.GF18768@tyan-ft48-01.lab.bos.redhat.com> <4F26BA55.firstname.lastname@example.org> <20120130161124.GH18768@tyan-ft48-01.lab.bos.redhat.com> <4F26FCF8.email@example.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Jan 30, 2012 at 03:26:32PM -0500, Jason Merrill wrote:
> On 01/30/2012 11:11 AM, Jakub Jelinek wrote:
> >Can't tlink just take into account that sometimes different
> >symbols mangle the same, and handle those as a group (i.e. if
> >the linker output requests S::~S(), and *.rpo files contain
> >several _ZN1SD[0-9]Ev symbols, mark or tweak them all)?
> Emitting one doesn't necessary imply emitting all of them. Perhaps
Sure, but would they ever be provided by different CUs? If some CU
says it can provide _ZN1SD1Ev, doesn't it either always say that
it can provide _ZN1SD2Ev, or none of the CU is able to provide the latter
(at least in valid C++ without ODR violations)?
I meant if the linker says it wants S::~S(), you'd see that in CU25
the rpo file offers both of them and you'd mark both for compilation.
> we could change the demangler to distinguish between the symbols,
> but of course that wouldn't affect current linkers.
> What if we use linker demangling only if the user has specified
> creating a linker map?
Do users really want to demangle linker maps? I would never want that,
e.g. because it is ambiguous and less compact.
IMHO the best is just to back out the changes that introduced this