<div dir="ltr">OK, thanks.<div><br></div><div>One more question: which part of the standard says you aren't allowed to take the addresses of methods of classes in the standard library?<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 12, 2016 at 6:16 PM, Evgenii Stepanov <span dir="ltr"><<a href="mailto:eugeni.stepanov@gmail.com" target="_blank">eugeni.stepanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
it's been put on hold for other higher priority work. I still want to<br>
get it done one day, but it's not clear when that would be.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Jul 12, 2016 at 6:11 PM, Akira Hatanaka <<a href="mailto:ahatanak@gmail.com">ahatanak@gmail.com</a>> wrote:<br>
> Hi Evgenii,<br>
><br>
> I was wondering what the status is of your work to attach "internal_linkage"<br>
> to methods of standard library classes in libc++. The following piece of<br>
> code doesn't link because a symbol (string::empty) is undefined and it<br>
> sounds like your work might fix the linkage error I'm seeing.<br>
><br>
> $ cat test1.cpp<br>
> #include <string><br>
> #include <functional><br>
><br>
> int main() {<br>
>   using namespace std::placeholders;<br>
>   auto b = std::bind(&std::string::empty, _1);<br>
> }<br>
><br>
> On Mon, Nov 9, 2015 at 1:58 PM, Evgenii Stepanov via llvm-dev<br>
> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> In fact, during the code review we've decided against allowing this<br>
>> attribute on namespaces: <a href="http://reviews.llvEm.org/D13925" rel="noreferrer" target="_blank">http://reviews.llvEm.org/D13925</a><br>
>><br>
>><br>
>> The intended use of this attribute in libc++ is on functions that<br>
>> programs are not allowed to take address of, like all methods of<br>
>> standard library classes. Visibility("hidden") attribute (which we are<br>
>> replacing with internal_linkage) violates ODR the same way.<br>
>><br>
>> Also, this attribute (for us) is not about locality or performance.<br>
>> Its primary purpose is to reliably exclude a class method from the<br>
>> export table. This is the way libc++ manages ABI stability: all class<br>
>> methods that are not part of the library ABI are defined in the<br>
>> headers with a set of attributes that ensure that they become internal<br>
>> to the translation unit. Always_inline does that in almost all cases,<br>
>> but almost is not good enough. Internal_linkage is a straighforward<br>
>> way to achieve the same.<br>
>><br>
>><br>
>> On Mon, Nov 9, 2015 at 1:34 PM, Martin J. O'Riordan<br>
>> <<a href="mailto:martin.oriordan@movidius.com">martin.oriordan@movidius.com</a>> wrote:<br>
>> > With respect only to '__attribute__((internal_linkage))', not 'nodebug'<br>
>> > and other parts of this topic; does hiding "some" members and not others not<br>
>> > introduce a violation of the ODR because some members of the class as it<br>
>> > appears in one translation unit are not the same actual definitions as the<br>
>> > apparently "same" members of the class in another translation unit?  In<br>
>> > particular the ODR requirement that would ensure that the address of a<br>
>> > method was the same regardless of where the address was taken, including<br>
>> > 'static' methods (no 'this' pointer)?  Or hidden things like the guard<br>
>> > variables for local static objects, default argument initialisers (which are<br>
>> > instanced), etc.?<br>
>> ><br>
>> > I must admit that having spent years trying to lock down the definition<br>
>> > of the ODR, that this seems to fly in the opposite direction of the intent<br>
>> > of that rule.<br>
>> ><br>
>> > I can (sort of) see why for particular reasons of locality you might<br>
>> > want multiple actual definitions, even though they might exhibit the same<br>
>> > behaviour, but maybe the answer for locality optimisation would be for the<br>
>> > linker technology to evolve so that multiple copies of the same definition<br>
>> > (sic) could be made; perhaps even at the Basic Block level [Block Level<br>
>> > Linking].  But this too would lie under the auspices of the "as if" rule and<br>
>> > respect the ODR.<br>
>> ><br>
>> > There is something I am missing in this that is not making me at all<br>
>> > comfortable about the use of this attribute for namespaces (apart from the<br>
>> > reopening issues raised by others), and in particular the application to<br>
>> > parts of a class but not the whole class.  I just feel that this is leading<br>
>> > to semantic trouble.<br>
>> ><br>
>> > Thanks,<br>
>> ><br>
>> >         MartinO<br>
>> ><br>
>> > -----Original Message-----<br>
>> > From: Evgenii Stepanov [mailto:<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>]<br>
>> > Sent: 09 November 2015 18:49<br>
>> > To: Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com">Paul_Robinson@playstation.sony.com</a>><br>
>> > Cc: Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>>;<br>
>> > <a href="mailto:sstewartgallus00@mylangara.bc.ca">sstewartgallus00@mylangara.bc.ca</a>; <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>; Martin J.<br>
>> > O'Riordan <<a href="mailto:martin.oriordan@movidius.com">martin.oriordan@movidius.com</a>><br>
>> > Subject: Re: [llvm-dev] [cfe-dev] [RFC]<br>
>> > __attribute__((internal_linkage))<br>
>> ><br>
>> > Sorry, I totally missed updates to this thread.<br>
>> ><br>
>> > Anonymous namespace does not work for libc++ because we need to hide<br>
>> > some class members, and export the rest. Namespace would hide all of them.<br>
>> > AFAIK, "static" is un-deprecated in C++11 for multiple reasons, including<br>
>> > this one.<br>
>> ><br>
>> > I agree that nodebug should not affect codegen. It would also kill debug<br>
>> > info (ex. all debug locations in libc++ headers).<br>
>> ><br>
>> ><br>
>> > On Mon, Nov 2, 2015 at 11:57 AM, Robinson, Paul via llvm-dev<br>
>> > <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >><br>
>> >><br>
>> >>> -----Original Message-----<br>
>> >>> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of<br>
>> >>> Chris Lattner via llvm-dev<br>
>> >>> Sent: Saturday, October 31, 2015 2:58 PM<br>
>> >>> To: <a href="mailto:sstewartgallus00@mylangara.bc.ca">sstewartgallus00@mylangara.bc.ca</a><br>
>> >>> Cc: LLVM Developers<br>
>> >>> Subject: Re: [llvm-dev] [cfe-dev] [RFC]<br>
>> >>> __attribute__((internal_linkage))<br>
>> >>><br>
>> >>> Hi Stewart,<br>
>> >>><br>
>> >>> I saw this get brought up at the LLVM devmtg in the context of<br>
>> >>> improving the stack size of libc++ frames.<br>
>> >>><br>
>> >>> Have you guys considered a different approach to solving this<br>
>> >>> problem?  In the case of libc++, the _LIBCPP_INLINE_VISIBILITY macro<br>
>> >>> currently expands out to "__attribute__ ((__always_inline__))”.  It<br>
>> >>> seems reasonable to me to have it also add the “nodebug” attribute as<br>
>> >>> well.  This should allow the allocas generated by inlining lots of<br>
>> >>> frames to be promoted to registers (because there is no debug info to<br>
>> >>> pessimize).<br>
>> >><br>
>> >> Are you suggesting that 'nodebug' should affect code generation?<br>
>> >> It most definitely should not...<br>
>> >> --paulr<br>
>> >><br>
>> >>><br>
>> >>> This would dramatically shrink the stack frames of code using libc++<br>
>> >>> at - O0, and would also make it go a lot faster.<br>
>> >>><br>
>> >>> -Chris<br>
>> >>><br>
>> >>><br>
>> >>> > On Oct 29, 2015, at 6:35 AM, Martin J. O'Riordan via llvm-dev<br>
>> >>> > <llvm-<br>
>> >>> <a href="mailto:dev@lists.llvm.org">dev@lists.llvm.org</a>> wrote:<br>
>> >>> ><br>
>> >>> > I haven't been able to figure out from this thread why this<br>
>> >>> > attribute is<br>
>> >>> necessary at all.<br>
>> >>> ><br>
>> >>> > Anonymous or unnamed namespaces were added to C++ for this very<br>
>> >>> > purpose,<br>
>> >>> but the ISO C++ Standard does not discuss "linkage" per-se because it<br>
>> >>> is outside the scope of the language specification.  But it does<br>
>> >>> describes it in terms of having a hidden name which is "unique" to<br>
>> >>> the translation unit, and under the "as if" rule, internal linkage is<br>
>> >>> a common convention for achieving this.<br>
>> >>> ><br>
>> >>> > This is just Standardese for dealing with what compiler<br>
>> >>> > implementers<br>
>> >>> typically handle as "internal linkage" anyway; at the same time, the<br>
>> >>> use of 'static' for this purpose was deprecated.  This is<br>
>> >>> specifically stated in C++98 section 7.3.1.1 and unnamed namespaces<br>
>> >>> are still similarly defined in C++17 (Working Paper) although the<br>
>> >>> specific reference to the deprecation of 'static' for this purpose is<br>
>> >>> now gone.<br>
>> >>> ><br>
>> >>> > The closest the Standard gets to talking about linkage is with<br>
>> >>> > Linkage<br>
>> >>> Specifications, and even here it tries to avoid to avoid treading on<br>
>> >>> the definitions things like internal versus external linkage.<br>
>> >>> ><br>
>> >>> > So I am curious, what does this proposed attribute on namespaces<br>
>> >>> > achieve<br>
>> >>> that cannot already be achieved with an anonymous or unnamed<br>
>> >>> namespace?<br>
>> >>> ><br>
>> >>> > Thanks,<br>
>> >>> ><br>
>> >>> >     Martin O'Riordan - Movidius Ltd.<br>
>> >>> ><br>
>> >>> > -----Original Message-----<br>
>> >>> > From: cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org">cfe-dev-bounces@lists.llvm.org</a>] On Behalf Of<br>
>> >>> Evgenii Stepanov via cfe-dev<br>
>> >>> > Sent: 23 October 2015 22:41<br>
>> >>> > To: Steven Stewart-Gallus <<a href="mailto:sstewartgallus00@mylangara.bc.ca">sstewartgallus00@mylangara.bc.ca</a>><br>
>> >>> > Cc: Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
>> >>> > Subject: Re: [cfe-dev] [RFC] __attribute__((internal_linkage))<br>
>> >>> ><br>
>> >>> > Sounds right. The proposed attribute is a rough equivalent of<br>
>> >>> ><br>
>> >>> > static void foo::do_method(void)<br>
>> >>> > {<br>
>> >>> >  // implementation here<br>
>> >>> > }<br>
>> >>> ><br>
>> >>> > where "static" does not mean a static class member, but makes the<br>
>> >>> declaration local to the translation unit. C-style "static".<br>
>> >>> ><br>
>> >>> > The patch in <a href="http://reviews.llvm.org/D13925" rel="noreferrer" target="_blank">http://reviews.llvm.org/D13925</a> (waiting for review,<br>
>> >>> > btw!)<br>
>> >>> supports this attribute on classes and namespaces, with this syntax:<br>
>> >>> ><br>
>> >>> > namespace __attribute__((internal_linkage)) { }<br>
>> >>> ><br>
>> >>> ><br>
>> >>> > On Fri, Oct 23, 2015 at 9:03 AM, Steven Stewart-Gallus via cfe-dev<br>
>> >>> > <cfe-<br>
>> >>> <a href="mailto:dev@lists.llvm.org">dev@lists.llvm.org</a>> wrote:<br>
>> >>> >> Hello,<br>
>> >>> >><br>
>> >>> >> Can I ask for some clarification?<br>
>> >>> >><br>
>> >>> >> Apparently, C++ doesn't allow to static class methods?<br>
>> >>> >><br>
>> >>> >> While in C one might write inside a header file:<br>
>> >>> >><br>
>> >>> >> static inline void mylib_foo_do_method(struct mylib_foo *foo) {<br>
>> >>> >>   // implementation here<br>
>> >>> >> }<br>
>> >>> >><br>
>> >>> >> In C++ the typical style would be to write something like:<br>
>> >>> >><br>
>> >>> >> namespace mylib {<br>
>> >>> >><br>
>> >>> >> void foo::do_method(void)<br>
>> >>> >> {<br>
>> >>> >>  // implementation here<br>
>> >>> >> }<br>
>> >>> >> }<br>
>> >>> >><br>
>> >>> >> Unfortunately, the C++ case then implies some linkage behaviour<br>
>> >>> >> that some might not want.<br>
>> >>> >><br>
>> >>> >> Apparently, one can't do things like:<br>
>> >>> >><br>
>> >>> >> namespace mylib {<br>
>> >>> >><br>
>> >>> >> static void foo::do_method(void)<br>
>> >>> >> {<br>
>> >>> >>  // implementation here<br>
>> >>> >> }<br>
>> >>> >> }<br>
>> >>> >><br>
>> >>> >> Or,<br>
>> >>> >><br>
>> >>> >> namespace {<br>
>> >>> >> namespace mylib {<br>
>> >>> >><br>
>> >>> >> static void foo::do_method(void)<br>
>> >>> >> {<br>
>> >>> >>  // implementation here<br>
>> >>> >> }<br>
>> >>> >> }<br>
>> >>> >> }<br>
>> >>> >><br>
>> >>> >> Also, if you wanted to an attribute to a whole namespace you<br>
>> >>> >> should do something like the following I think:<br>
>> >>> >><br>
>> >>> >> namespace mylib {<br>
>> >>> >> [[clang::internal_linkage]];<br>
>> >>> >><br>
>> >>> >> static void foo::do_method(void)<br>
>> >>> >> {<br>
>> >>> >>  // implementation here<br>
>> >>> >> }<br>
>> >>> >> }<br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> Thank you,<br>
>> >>> >> Steven Stewart-Gallus<br>
>> >>> >> _______________________________________________<br>
>> >>> >> cfe-dev mailing list<br>
>> >>> >> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> >>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>> >>> > _______________________________________________<br>
>> >>> > cfe-dev mailing list<br>
>> >>> > <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> >>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>> >>> ><br>
>> >>> > _______________________________________________<br>
>> >>> > LLVM Developers mailing list<br>
>> >>> > <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> >>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> >>><br>
>> >>> _______________________________________________<br>
>> >>> LLVM Developers mailing list<br>
>> >>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> >>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> >> _______________________________________________<br>
>> >> LLVM Developers mailing list<br>
>> >> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> ><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div></div>