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