[DOC]: Does libcu++ support non-CUDA compilers?

[bernhardmgruber]

Is this a duplicate?

• [X] I confirmed there appear to be no duplicate issues for this bug and that I agree to the Code of Conduct

Is this for new documentation, or an update to existing docs?

New

Describe the incorrect/future/missing documentation

The documentation of libcu++ specifies the following:

• std:: / <*>: This is your host compiler's Standard Library that works in __host__ code only, although you can use the --expt-relaxed-constexpr flag to use any constexpr functions in __device__ code. libcu++ does not replace or interfere with host compiler's Standard Library.
• cuda::std:: / <cuda/std/*>: Conforming implementations of facilities from the Standard Library that work in __host__ __device__ code.
• cuda:: / <cuda/*>: Conforming extensions to the Standard Library that work in __host__ __device__ code.
• cuda::device / <cuda/device/*>: Conforming extensions to the Standard Library that work only in __device__ code.
• cuda::ptx: C++ convenience wrappers for inline PTX (only usable in __device__ code).

However, it does not specify whether "works in __host__ code" implies that it can be compiled by a non-CUDA compiler like g++. This is highly desirable though and appears to be existing practice. Thrust's TBB and OMP backends for example can be compiled by several non-CUDA compilers (e.g. g++, clang, icpc, msvc, nvc++, etc.) and Thrust uses libcu++ in a lot of places already.

I would like the documentation of libcu++ to explicitly point out support for non-CUDA compilers for every feature supported in __host__ code.

If this is a correction, please provide a link to the incorrect documentation. If this is a new documentation request, please link to where you have looked.

No response

[bernhardmgruber]

I just discussed this with @wmaxey and he confirmed that __host__ code should also work when being compiled with a non-CUDA compiler like g++.

[jrhemstad]

I think this may be redundant with https://github.com/NVIDIA/cccl/issues/1374

[bernhardmgruber]

I think this may be redundant with #1374

It is.