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

[Larisse Voufo]

On Wed, Feb 25, 2015 at 9:06 PM, John McCall <rjmccall at apple.com> wrote:

> On Feb 25, 2015, at 5:16 PM, Larisse Voufo <lvoufo at google.com> wrote:
> 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.
>
>
> That’s just a symptom of the general problems caused by emitting this as a
> weak definition.  I think we need a better solution.
>

I do agree with you that we need a better solution, and we are working on
that. In the meantime, we need to at least be compliant with the standard,
and do our best not to break existing C++11 code.
Have you seen r230580? What do you have in mind? I'm curious.



> John.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150226/776fd8ef/attachment.html>