<atomic>: std::atomic_ref<volatile T> compilation-errors

[lewissbaker]

Describe the bug

The following code-snippet fails to compile under latest MSVC.

#include <atomic>

void test() {
    volatile int vi = 0;
    std::atomic_ref<volatile int> vref(vi);
    int val = vref.load(); // ok
    vref.exchange(val); // ok
    vref.fetch_add(0); // warning
    vref.fetch_sub(0); // warning
    vref.fetch_or(0); // warning
    vref.compare_exchange_weak(val, 0); // error
    vref.compare_exchange_strong(val, 0); // error
    vref.wait(0); // error
}

See https://godbolt.org/z/f5jP7zs5G

Expected behavior

I expected this code-snippet to compile successfully.

We should be able to use std::atomic_ref<volatile int> to read/write atomically to storage pointed to by a volatile int*. e.g. for storage mapped in via shared-memory.

STL version

Whatever is running in the current compiler-explorer under 'x64 msvc v19.latest'. Diagnostic paths include '14.39.33321-Pre'

Additional context

Also potentially related - see Wg21 mailing list thread on potential specification issue relating to std::atomic_ref<volatile T>. https://lists.isocpp.org/lib/2024/06/28451.php

Other standard libraries also seem to have similar issues:

• https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115402
• https://github.com/llvm/llvm-project/issues/94879

[frederick-vs-ja]

A volatile version of memcpy seems necessary for correct writing...

[pinskia]

https://cplusplus.github.io/LWG/issue3508

[StephanTLavavej]

Thanks @pinskia - this is definitely blocked on LWG-3508 that @CaseyCarter filed back in 2020. That needs to be resolved before we'll know what to do here.

[lewissbaker]

The paper https://isocpp.org/files/papers/P3323R0.html proposes some improvements to std::atomic_ref to address some of the issues around use with cv-qualified types.