Jake Hemstad

It looks like this was caused by a recent change in libstdc++ here: https://github.com/gcc-mirror/gcc/commit/dbf8bd3c2f2cd2d27ca4f0fe379bd9490273c6d7#diff-b358f609a31a4af8af72cc3197566abaa157bb7f8681b45580f1e5477540457cR192-R193 However, this issue is unique to `clang` as `nvcc` compiles the equivalent just fine: ``` __attribute__...

I think `std::format` is going to be much more feasible than `std::cout`.

This looks like it was fixed for 11.4+, but is still present in 11.0.2 and 11.0.3. https://godbolt.org/z/9zvb71vzx

@PointKernel did you test the latest libcu++ from GH against nvcc 11.5.50 and 11.5.119? Or were you testing the libcu++ version that was alongside 11.5.50 and 11.5.119?

Can you verify if the issue persists with the current libcu++ in GH against those compiler versions?

@wmaxey I thought this would have gone away with the `atomic` refactor, but it seems to still be around.

> I'd really rather not call it `polymorphic`. It's a bad name, it's not important for the user to know that, and some classes of performance-sensitive users are allergic to...

There currently isn't a guarantee that libcu++ can be compiled solely by a host compiler. See https://github.com/NVIDIA/libcudacxx/issues/16

There's a usability issue with the current design of `memory_kind` and templating `memory_resource` on `memory_kind`. Let's say I have a function that expects a resource that can allocate memory accessible...

fyi, this has become incredibly out of date with the current design. I will be working on updating the design document.