<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 24, 2015 at 2:50 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><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">lvoufo@google.com</a>> wrote:<br>
> Author: lvoufo<br>
> Date: Tue Feb  3 20:34:32 2015<br>
> New Revision: 228107<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=228107&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=228107&view=rev</a><br>
> Log:<br>
> Generalize r228066 to give all implicit global allocation functions default visibility.<br>
<br>
</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>
<br>
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><br></div><div> </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><br></div><div>This has fixed a lot of issues with </div><div>"<span style="color:rgb(0,0,0);line-height:18.5919990539551px;white-space:pre-wrap">warning: Cannot export local symbol 'operator delete(void*, unsigned long)'</span>"</div><div>where the sized delete symbol was exported from a file that made use of the symbol and</div><div>depended on another file that was compiled with hidden visibility.</div><div><br></div><div> </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">all it does it create unnecessary and probably unwanted work at load-time to dynamically merge symbols.<br>
<span class=""><font color="#888888"><br>
John.</font></span></blockquote></div><br></div></div>