<html>
    <head>
      <base href="https://bugs.llvm.org/">
    </head>
    <body><span class="vcard"><a class="email" href="mailto:dimitry@andric.com" title="Dimitry Andric <dimitry@andric.com>"> <span class="fn">Dimitry Andric</span></a>
</span> changed
          <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - Initializing shared_ptr with make_shared should not call destructor"
   href="https://bugs.llvm.org/show_bug.cgi?id=50369">bug 50369</a>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">CC</td>
           <td>
                
           </td>
           <td>dimitry@andric.com, ldionne@apple.com
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Status</td>
           <td>NEW
           </td>
           <td>RESOLVED
           </td>
         </tr>

         <tr>
           <td style="text-align:right;">Resolution</td>
           <td>---
           </td>
           <td>FIXED
           </td>
         </tr></table>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - Initializing shared_ptr with make_shared should not call destructor"
   href="https://bugs.llvm.org/show_bug.cgi?id=50369#c1">Comment # 1</a>
              on <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - Initializing shared_ptr with make_shared should not call destructor"
   href="https://bugs.llvm.org/show_bug.cgi?id=50369">bug 50369</a>
              from <span class="vcard"><a class="email" href="mailto:dimitry@andric.com" title="Dimitry Andric <dimitry@andric.com>"> <span class="fn">Dimitry Andric</span></a>
</span></b>
        <pre>This was fixed in (or at least a side-effect of)
<a href="https://github.com/llvm/llvm-project/commit/955dd7b7f3f6">https://github.com/llvm/llvm-project/commit/955dd7b7f3f6</a> by Louis Dionne (on
2021-12-11), in relation to <a class="bz_bug_link 
          bz_status_RESOLVED  bz_closed"
   title="RESOLVED FIXED - std::allocate_shared can't allocate object with private constructor"
   href="show_bug.cgi?id=41900">bug 41900</a>:

<span class="quote">> [libc++] LWG2070: Use Allocator construction for objects created with allocate_shared</span >
>
<span class="quote">> 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.</span >
>
<span class="quote">> This change is landed separately from the rest of P0674R1 because it is
> incredibly tricky from an ABI perspective.</span >
>
<span class="quote">> 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.</span >
>
<span class="quote">> Fixes <a href="https://llvm.org/PR41900">https://llvm.org/PR41900</a>
> Supersedes <a href="https://llvm.org/D62760">https://llvm.org/D62760</a></span >
>
<span class="quote">> Differential Revision: <a href="https://reviews.llvm.org/D91201">https://reviews.llvm.org/D91201</a></span >

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.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>