<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 23, 2018, at 16:05, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Aug 22, 2018 at 3:02 PM Louis Dionne <<a href="mailto:ldionne@apple.com" class="">ldionne@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class=""><div class="">The problem here is that there's no function in the dylib that we can call that would itself have access to __vector_base_common<true>::__vector_base_common(), which has hidden visibility.</div><div class=""><br class=""></div><div class="">Also, even disregarding this issue, it turns out that preventing inlining of all methods that are part of the ABI is kind of a big deal -- I'm quite concerned about the performance impact this could have. I’d much rather pursue a path that does not require telling the compiler whether to inline something or not, as this is an orthogonal decision IMO. Does that make sense?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">True, if the dylib does not provide the symbols that are being called directly from user code, then neither of my suggestions will help. You really do need to emit the functions with linkonce_odr linkage, because they are not actually available, and the extern template declaration is a bit of a lie.</div></div></div></div></blockquote><div><br class=""></div><div>Yes, it is indeed a lie. More specifically, the extern template declaration is a lie for a subset of the methods in the class template — some of them are actually in the dylib, but some of them are not.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">At this point, you might want to consider finding a way to make libc++.dylib expose the symbols so that at some point in the future so that these functions can be emitted as avaiable_externally instead of linkonce_odr.</div></div></div>
</div></blockquote></div><div class=""><br class=""></div>The problem is that we don’t want to increase the surface of the ABI if we can avoid it. The larger our ABI surface is, the harder it is to make changes because we need to maintain ABI stability.<div class=""><br class=""></div><div class="">Louis<br class=""><div class=""><br class=""></div></div></body></html>