NVIDIA / NVIDIA/cccl

[libcu++] atomic<T> fails to compile for non-power-of-two sizes under CUDA compilation

Open
#10,967 2 comments 0 reactions 1 assignee Claimed by @griwes View on GitHub
needs triage
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.