[libcu++] Fix default make_shared_resource construction#9044
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughSummary by CodeRabbit
suggestion: WalkthroughAdds an in-place constructor to __shared_block_ptr and updates shared_resource argument forwarding so make_shared_resource() with no arguments default-constructs T. Adds a test verifying a single construction and non-null allocate_sync. ChangesIn-place construction support for shared_resource
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Comment |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
🥳 CI Workflow Results🟩 Finished in 2h 16m: Pass: 100%/116 | Total: 2d 13h | Max: 2h 14m | Hits: 81%/419684See results here. |
|
Successfully created backport PR for |
| //! @brief Constructs a new control block, forwarding arguments to the payload. | ||
| template <class... _Args> | ||
| _CCCL_HOST_API explicit __shared_block_ptr(::cuda::std::in_place_type_t<_Payload>, _Args&&... __args) | ||
| : __block_(new __block_t(::cuda::std::forward<_Args>(__args)...)) | ||
| {} | ||
|
|
||
| //! @brief Constructs a new control block, forwarding arguments to the payload. | ||
| _CCCL_TEMPLATE(class _Arg, class... _Rest) | ||
| _CCCL_REQUIRES((!::cuda::std::is_same_v<::cuda::std::remove_cvref_t<_Arg>, __shared_block_ptr>) ) | ||
| _CCCL_REQUIRES( | ||
| (!::cuda::std::is_same_v<::cuda::std::remove_cvref_t<_Arg>, __shared_block_ptr>) | ||
| && (!::cuda::std::is_same_v<::cuda::std::remove_cvref_t<_Arg>, ::cuda::std::in_place_type_t<_Payload>>) ) | ||
| _CCCL_HOST_API explicit __shared_block_ptr(_Arg&& __arg, _Rest&&... __rest) | ||
| : __block_(new __block_t(::cuda::std::forward<_Arg>(__arg), ::cuda::std::forward<_Rest>(__rest)...)) | ||
| {} |
There was a problem hiding this comment.
I believe the additional constraint should not be necessary. We should probably just require everybody to use in_place
There was a problem hiding this comment.
Happy to do this in a follow-up but we need to land the backport first to get CI unblocked for RAPIDS.
GCC 7 jobs failed without the additional constraint (ambiguous with two forwarding constructors).
There is a bug in CCCL's `make_shared_resource<T>()` that doesn't work with types that have no constructor arguments. NVIDIA/cccl#9043 NVIDIA/cccl#9044 fixes it, but we need a workaround to unblock CI until that is backported (NVIDIA/cccl#9047) and rapids-cmake is updated. Authors: - Bradley Dice (https://github.com/bdice) Approvers: - David Wendt (https://github.com/davidwendt) URL: #2406
Description
closes #9043
Adds coverage for zero-argument
cuda::mr::make_shared_resource<T>()with a default-constructible resource, and fixesshared_resource<T>(in_place_type<T>)so it constructs aTeven when no constructor arguments are provided.The fix preserves null default construction for
__shared_block_ptr<T>by adding an explicit in-place payload construction path.Tested with:
CCCL_BUILD_INFIX=opencode cmake --preset libcudacxx-cpp17 -DCMAKE_CUDA_ARCHITECTURES=native cmake --build /home/coder/cccl/build/opencode/libcudacxx-cpp17 --target libcudacxx.test.cuda.memory_resource.shared_resource -j ctest --test-dir /home/coder/cccl/build/opencode/libcudacxx-cpp17 -R '^libcudacxx\.test\.cuda\.memory_resource\.shared_resource$' --output-on-failureChecklist