> On Feb 25, 2015, at 5:16 PM, Larisse Voufo <[email protected]> wrote:
> On Tue, Feb 24, 2015 at 2:50 PM, John McCall <[email protected]
> <mailto:[email protected]>> wrote:
> > On Feb 3, 2015, at 6:34 PM, Larisse Voufo <[email protected]
> > <mailto:[email protected]>> 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
> > <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.
That’s just a symptom of the general problems caused by emitting this as a weak
definition. I think we need a better solution.
John.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
