[libcu++] atomic<T> fails to compile for non-power-of-two sizes under CUDA compilation
- Dominant language
- C++
- Stars
- 2.5k
- Forks
- 486
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 295
Description
### Is this a duplicate?
- [x] I did not find any issue that matches what I described.
### What happens?
Under CUDA compilation, `_CCCL_ATOMIC_ALWAYS_LOCK_FREE` reports every type of at most 8 bytes as always lock-free. For sizes that are not powers of two (3, 5, 6, 7 bytes) that routes `cuda::std::atomic` into the plain storage, whose `_CCCL_ALIGNAS(sizeof(_Tp))` is ill-formed for non-power-of-two alignments, so valid programs fail to compile:
```
libcudacxx/include/cuda/std/__atomic/types/base.h(46): error: invalid alignment value specified by attribute
__attribute__((__aligned__(sizeof(_Tp)))) _Tp __a_value;
```
Reproducer:
```cpp
#include
#include
cuda::std::atomic<::cuda::std::array> a;
```
This fails on nvcc device passes while host-only compilers accept it, because there the lock-free predicate comes from `__atomic_always_lock_free`, which is false for these sizes. PTX hardware atomics only exist at 8/16/32/64/128-bit widths, so sizes like 5..7 are genuinely not lock-free on device and must take the small or locked storage path.
The runtime `is_lock_free()` predicate (`_LIBCUDACXX_ATOMIC_IS_LOCK_FREE`) has the same missing power-of-two check, and so does the fallback trait used when the macro is undefined.
### How do we reproduce?
Compile the two lines above with any recent nvcc for a device target.
Contributor guide
Assessment
This issue has not been assessed yet.