On Wed, Feb 25, 2015 at 9:06 PM, John McCall <[email protected]> wrote:
> 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]> 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. > > > 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. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
