[cfe-dev] libc++ is not using always_inline anymore!

[Mehdi AMINI via cfe-dev]

Le mar. 30 oct. 2018 à 15:57, Louis Dionne via cfe-dev <
cfe-dev at lists.llvm.org> a écrit :

>
> On Oct 30, 2018, at 18:00, David Blaikie <dblaikie at gmail.com> wrote:
>
> Awesome!
>
> What are the new semantics? That this ABI stability guarantee is provided
> by hiding the functions in each user so they can't be deduplicated with
> anotehr user's copy? (what about other copies that are from the same build?
> I guess even those won't get coalesced/collapsed together? Would that be
> useful to support?)
>
>
> There are currently two modes (in LLVM trunk, and that is the plan for
> LLVM 8 too):
>
> 1. (the default) All TUs linked together inside the same final linked
> image need to have use the same libc++ version. Inline functions are
> ODR-merged across TUs like they normally are. In this mode, we don't use
> any funny attribute to control linkage (neither always_inline nor
> internal_linkage).
>
> 2. (can be opted-in) TUs can be linked together even if they use different
> headers of libc++. This is achieved by using internal_linkage on
> implementation detail functions of libc++. Those functions are local to a
> TU and they are NOT ODR-merge across TUs. This results in more code
> duplication than option (1).
>
>
> I assume this doesn't change the defaults, but does it make it any easier
> for users who don't need the ABI stability guarantee? (or was it already
> easy/no change here?)
>
>
> It actually does change the default. However, it depends of what ABI
> guarantee you're talking about.
>
> 1. The ABI stability of the shared objects is always (and has always been,
> and will most likely always) be guaranteed. The only way to change that is
> to explicitly use the _LIBCPP_ABI_UNSTABLE macro, which says "use all the
> ABI breaking features". This obviously only works if you're also linking
> against a library that was built to provide that ABI. This ability to use
> the unstable ABI has been provided for a long time, it wasn't the default,
> and it still isn't the default -- my change is completely orthogonal to
> that.
>
> 2. The "ABI stability" of static archives is a different matter. The
> question here is whether you can link programs against static archives
> built with different versions of libc++. The answer used to be YES by
> default, not it is NO by default. If you want to retain that ability, you
> need to use the `_LIBCPP_HIDE_FROM_ABI_PER_TU` macro. And also please give
> us a heads up so we know someone is using it.
>

In general I'm worried of "undefined behavior" that isn't caught by a tool,
ideally at build time otherwise at runtime. I would really encourage to not
introduce any default behavior where you can't provide an easy detection
mechanism to the user.

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181110/56a75af1/attachment.html>