On Tue, Feb 24, 2015 at 2:50 PM, John McCall <[email protected]> wrote:
> > On Feb 3, 2015, at 6:34 PM, Larisse Voufo <[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 > > 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
