r228107 - Generalize r228066 to give all implicit global allocation functions default visibility.

[Larisse Voufo]

On Tue, Feb 24, 2015 at 2:50 PM, John McCall <rjmccall at apple.com> wrote:

> > On Feb 3, 2015, at 6:34 PM, Larisse Voufo <lvoufo at google.com> wrote:
> > Author: lvoufo
> > Date: Tue Feb  3 20:34:32 2015
> > New Revision: 228107
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=228107&view=rev
> > Log:
> > Generalize r228066 to give all implicit global allocation functions
> default visibility.
>
> This seems generally correct, but I’m suspicious about applying it to the
> implicit C++14 compatibility definitions.  Linkers are not generally going
> to give this sensible behavior: the static linker will prefer the first
> definition on the link line, and the dynamic linker will prefer a
> definition in the executable over one in the standard library.  So even if
> there’s a usefully optimized implementation of sized deallocation in the
> program, it’ll probably get clobbered by one of these useless ones.
>
> I don’t think there’s really a fix for that except to actually trust
> declarations from the standard library if they exist.  (Assuming we don’t
> have lying library headers out there, which we might.)  And if they don’t
> exist, it’s fine to emit these compatibility definitions, but




> we shouldn’t pretend that giving them default visibility is useful;


This has fixed a lot of issues with
"warning: Cannot export local symbol 'operator delete(void*, unsigned long)'
"
where the sized delete symbol was exported from a file that made use of the
symbol and
depended on another file that was compiled with hidden visibility.



> all it does it create unnecessary and probably unwanted work at load-time
> to dynamically merge symbols.
>
> John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150225/a09b2fbc/attachment.html>