[llvm-bugs] [Bug 41900] std::allocate_shared can't allocate object with private constructor

[via llvm-bugs]

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

Louis Dionne <ldionne at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ldionne at apple.com
         Resolution|---                         |FIXED
 Fixed By Commit(s)|                            |955dd7b7f3f6df79f573508ffb5
                   |                            |67f3923e892f7
             Status|NEW                         |RESOLVED

--- Comment #11 from Louis Dionne <ldionne at apple.com> ---
This should have been fixed by https://reviews.llvm.org/D91201. Please reopen
if you still see the original issue (or another issue!).

commit 955dd7b7f3f6df79f573508ffb567f3923e892f7
Author: Louis Dionne <ldionne.2 at gmail.com>
Date:   Fri Dec 11 12:22:16 2020 -0500

    [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

-- 
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/20210108/1979f081/attachment.html>