This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR 51910, -frepo/linker demangling interaction


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]