This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction
- From: Jason Merrill <jason at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 01 Feb 2012 10:20:33 -0500
- 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> <20120201135629.GR18768@tyan-ft48-01.lab.bos.redhat.com>
On 02/01/2012 08:56 AM, Jakub Jelinek wrote:
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.
That might result in emitting variants that aren't needed, but I suppose
that isn't so bad. I'll give it a shot.
Do users really want to demangle linker maps? I would never want that,
e.g. because it is ambiguous and less compact.
I'm surprised by that too, but apparently CodeSourcery clients do want that.