<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Feb 26, 2015, at 9:36 AM, Larisse Voufo <<a href="mailto:lvoufo@google.com" class="">lvoufo@google.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 25, 2015 at 9:06 PM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class="h5"><div class=""><blockquote type="cite" class=""><div class="">On Feb 25, 2015, at 5:16 PM, Larisse Voufo <<a href="mailto:lvoufo@google.com" target="_blank" class="">lvoufo@google.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 24, 2015 at 2:50 PM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> On Feb 3, 2015, at 6:34 PM, Larisse Voufo <<a href="mailto:lvoufo@google.com" target="_blank" class="">lvoufo@google.com</a>> wrote:<br class="">
> Author: lvoufo<br class="">
> Date: Tue Feb 3 20:34:32 2015<br class="">
> New Revision: 228107<br class="">
><br class="">
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=228107&view=rev" target="_blank" class="">http://llvm.org/viewvc/llvm-project?rev=228107&view=rev</a><br class="">
> Log:<br class="">
> Generalize r228066 to give all implicit global allocation functions default visibility.<br class="">
<br class="">
</span>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.<br class="">
<br class="">
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 </blockquote><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">we shouldn’t pretend that giving them default visibility is useful; </blockquote><div class=""><br class=""></div><div class="">This has fixed a lot of issues with </div><div class="">"<span style="line-height:18.5919990539551px;white-space:pre-wrap" class="">warning: Cannot export local symbol 'operator delete(void*, unsigned long)'</span>"</div><div class="">where the sized delete symbol was exported from a file that made use of the symbol and</div><div class="">depended on another file that was compiled with hidden visibility.</div></div></div></div></div></blockquote><div class=""><br class=""></div></div></div></div>That’s just a symptom of the general problems caused by emitting this as a weak definition. I think we need a better solution.</div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></div></div></blockquote><div><br class=""></div><div>I’m not suggesting that your patch should have been immediately reverted. It was causing us enough problems that we did need to revert it internally, but that’s our problem, not the community’s. I just want to make sure that we fix it properly.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Have you seen <span style="font-family:Arial,Helvetica,sans-serif;font-size:13px;line-height:18px" class="">r230580</span>? What do you have in mind? I'm curious.</div></div></div></div></div></blockquote><div><br class=""></div><div>After discussion with Richard, this is fine except that it needs to be controllable by a compiler option. What r230580 implements is standard-compliant, so making it the default behavior is reasonable, but it's not really what anybody wants. People who care about performance will want to skip this check, either by forcing it to true (because they’ve taken action to ensure that the sized deallocator exists and is implemented efficiently) or forcing it to false (because they’re sure enough that the sized deallocator doesn't exist, or doesn’t have an optimized representation, that they don’t want to pay for the extra overhead).</div><div><br class=""></div><div>John.</div></div></body></html>