<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 15, 2018, at 09:29, Louis Dionne <<a href="mailto:ldionne@apple.com" class="">ldionne@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br class="" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="">On Aug 15, 2018, at 12:27, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" class="">dexonsmith@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug. 14, 2018, at 13:43, Louis Dionne <<a href="mailto:ldionne@apple.com" class="">ldionne@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 14, 2018, at 13:56, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="">On Aug 14, 2018, at 1:19 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com" class="">dexonsmith@apple.com</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I support this change too.<div class=""><br class=""></div><div class="">At least in the short term, I think vendors should still have the capability to provide this guarantee without user opt-in by changing the default macro settings (switching it to a user opt-out).<br class=""></div></div></div></blockquote><div class=""><br class=""></div>I agree with both of these points.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I implemented these in the latest revision of <a href="https://reviews.llvm.org/D50652" class="">https://reviews.llvm.org/D50652</a>.</div><div class=""><br class=""></div><div class="">With <a href="https://reviews.llvm.org/D50652" class="">https://reviews.llvm.org/D50652</a>, by default, internal_linkage is NOT used and it is NOT safe to link TUs compiled with different versions of libc++. When _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE is defined, internal_linkage is used and it IS safe again to link TUs compiled with different versions of libc++.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I may be confused about the meaning of the patch, but it looks to me like that macro is choosing between two ways of making such TU-libc++-version-mixing safe: always_inline and internal_linkage. Which seems like a good thing, but distinct.</div></div></div></div></blockquote><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class=""></div><div style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">That’s the _current_ implementation, just because we can’t get rid of __always_inline__ without getting link errors. The _contract_ implied by not defining _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE is still that TUs can’t be linked if they’ve been compiled with different versions of libc++. In the not-too-distant future, we can drop __always_inline__ and replace it by something that allows odr-deduplication.</div></div></blockquote><div><br class=""></div><div>We chatted offline, but I forgot to update this cfe-dev post: this makes sense to me as long as we use a macro name that indicates the guarantee rather than the mechanism. (I believe Louis went with ..._HIDE_FROM_ABI_PER_TU, which WFM.)</div><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class="">To make that the default behavior, libc++ can be configured with `cmake <…> -DLIBCXX_ABI_HIDDEN_USE_INTERNAL_LINKAGE=ON` and _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE will be defined by default.</div><div class=""><br class=""></div><div class="">Bikeshedding on the name of that option is welcome on the review page — but I’d like to keep the form _LIBCPP_ABI_XXX to be consistent with other ABI-related macros.</div><div class=""><br class=""></div><div class="">Louis</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><br class=""></div><div class="">John.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug. 14, 2018, at 10:11, 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="">I 100% support not providing this guarantee by default. It always seemed a bit too heroic to me for libc++ to try to provide this support.<div class=""><br class=""></div><div class="">I think most people with standard library version skew typically only have skew between separate DSOs.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Aug 14, 2018 at 6:49 AM Louis Dionne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Hi,<br class=""><br class="">libc++ currently allows TUs that were built using different versions of libc++ to be linked together. Roughly speaking, this is achieved by making sure that anything not ABI-stable is local to each TU. This also allows distributing a static archive without caring too much about the version of libc++ it was compiled with, at least in principle. Supporting this use case creates code bloat for all users of libc++, since private functions are duplicated in each TU.<br class=""><br class="">I posit that few clients actually care about this, yet everybody is paying for it in terms of executable size. Hence, I would like to change the default guarantee offered by libc++ from "this use case is supported" to "this use case is not supported". The use case would still be supported by defining a macro for those that need it.<br class=""><br class="">Does anybody have objections to this change?<br class=""><br class="">Louis<br class="">_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></blockquote></div></div></blockquote></div></div></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></blockquote></div><br class=""></body></html>