search for: linkonce_odr_for_linker

...el them more orthogonally. That would be a major change in representation, though. Absent the will to do that, I propose that we: - remove/deprecate protected visibility, making visibility purely a hidden vs. non-hidden flag - add weak_for_linker, weak_odr_for_linker, linkonce_for_linker, and linkonce_odr_for_linker (better names highly desired) to model the weak-with-protected-visibility cases - add strong_for_linker (better name highly desired) to model the strong-but-interposable case John. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail...

...default visibility in the ELF sense, so it’s silly to pretend that LLVM visibility is the same as ELF visibility. ELF protected visibility is basically the semantics LLVM already assigns to default visibility. >> - add weak_for_linker, weak_odr_for_linker, linkonce_for_linker, and >> linkonce_odr_for_linker (better names highly desired) to model the >> weak-with-protected-visibility cases >> - add strong_for_linker (better name highly desired) to model the >> strong-but-interposable case > > For representing interposition we would only need one extra linkage > type: interp...

> On Mar 11, 2016, at 8:33 AM, Reid Kleckner <rnk at google.com> wrote: > On Thu, Mar 10, 2016 at 10:32 PM, John McCall via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > I mean, I’ve never really liked ELF’s stance on symbol interposition, but taking it as given, I’m not sure I agree that it’s reasonable to carve out virtual functions