[llvm-bugs] [Bug 50369] Initializing shared_ptr with make_shared should not call destructor

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50369

Dimitry Andric <dimitry at andric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dimitry at andric.com,
                   |                            |ldionne at apple.com
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #1 from Dimitry Andric <dimitry at andric.com> ---
This was fixed in (or at least a side-effect of)
https://github.com/llvm/llvm-project/commit/955dd7b7f3f6 by Louis Dionne (on
2021-12-11), in relation to bug 41900:

> [libc++] LWG2070: Use Allocator construction for objects created with allocate_shared
>
> This patch updates `allocate_shared` to call `allocator_traits::construct`
> when creating the object held inside the shared_pointer, and
> `allocator_traits::destroy` when destroying it. This resolves
> the part of P0674R1 that was originally filed as LWG2070.
>
> This change is landed separately from the rest of P0674R1 because it is
> incredibly tricky from an ABI perspective.
>
> This is the reason why this change is so tricky is that we previously
> used EBO in a compressed pair to store both the allocator and the object
> type stored in the `shared_ptr`. However, starting in C++20, P0674
> requires us to use Allocator construction for initializing the object type.
> That requirement rules out the use of the EBO for the object type, since
> using the EBO implies that the base will be initialized when the control
> block is initialized (and hence we can't do it through Allocator construction).
> Hence, supporting P0674 requires changing how we store the object type
> inside the control block, which we do while being ABI compatible by using
> some trickery with a properly aligned char buffer.
>
> Fixes https://llvm.org/PR41900
> Supersedes https://llvm.org/D62760
>
> Differential Revision: https://reviews.llvm.org/D91201

But Apple has not applied this to the copy of libc++ in Xcode (at least not the
version 12.5 I have here), probably due to the ABI issues mentioned in the
commit message, or because it is relatively new, and their version always lags
behind a bit.

That said, maybe you can report this separately to Apple, so they won't forget
about it? :)

Note also that Apple's clang still defaults to c++98, but if you use c++11 or
higher, the copy constructor is *not* called.

E.g. on macOS 11.3.1 (Big Sur) with Xcode 12.5:

% clang -v
Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: arm64-apple-darwin20.4.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

% clang++ -std=c++98 pr50369.cpp -o pr50369-c++98 && ./pr50369-c++98
constructor
copy
destructor
destructor

% clang++ -std=c++11 pr50369.cpp -o pr50369-c++11 && ./pr50369-c++11
constructor
destructor

In short, always explicitly specify the C++ standard when compiling on macOS.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210517/c74d75ad/attachment.html>