After Atomic Acquire, shouldn't we re-read previously read objects (if source code re-reads them) ?

[DoctorNoobingstoneIPresume]

Dear Programmers of Clang,

#include <atomic>

int ButWeAcquire (const int *pt)
{
    const std::atomic <int> *const pat {static_cast <const std::atomic <int> *> (static_cast <const void *> (pt))};
    static_assert (sizeof *pat == sizeof *pt);

    const T t0 {*pt};
    const T t1 {*pat};
    const T t2 {*pt};

    return t0 + t1 - t2;
}

Clang (but not GCC) seems to optimize away the last load operation (for t2):

https://godbolt.org/z/3resvraz9:
Compiling with -D'NDEBUG' -f'strict-aliasing' -O2 -g results in:

ButWeAcquire(int const*):
        mov     eax, dword ptr [rdi]
        mov     ecx, dword ptr [rdi]
        ret

or, for armv7-a:

ButWeAcquire(int const*):
        ldr     r1, [r0]
        ldr     r0, [r0]
        mov     r2, #0
        mov     r0, r1
        mcr     p15, #0, r2, c7, c10, #5
        bx      lr

or, for armv8-a:

ButWeAcquire(int const*):
        ldr     w8, [x0]
        ldar    wzr, [x0]
        mov     w0, w8
        ret

For me it would appear that the loading for t1 should Acquire effects by another thread which performs Release on the same memory address,

and those effects might include stores by that other thread to *pt (well, to the same memory address).

I am wrong somewhere, am I not ?

Maybe I should have written not "... Release on the same memory address", but rather "... Release on the same atomic object", and the atomic object is not shared with any other piece of code, please ?

Or is this really a bug ?

Thank you !!

[keinflue]

The function always has undefined behavior.

There are only two choices that could make any sense, either pt is actually a pointer pointing to an int object, or it is a (mistyped) pointer pointing to a std::atomic<int> object.

Either way, it can't be both. Regardless you access the object with both types, one of which must be an aliasing violation.

I am assuming that you you were trying to avoid that aliasing violation causing problems with -fno-strict-aliasing and misspelled it as -fstrict-aliasing, but I am not sure that this can help you here either.

Suppose you did use std::atomic_ref instead, which can be used to temporarily make an object atomic without aliasing violations:

using T = int;
T ButWeAcquire (const T *pt)
{
    auto pat = std::atomic_ref<int>(*pt);
    static_assert(alignof(T) >= std::atomic_ref<int>::required_alignment);

    const T t0 {*pt};
    const T t1 {pat};
    const T t2 {*pt};

    return t0 + t1 - t2;
}

now you can can drop -fno-strict-aliasing. Also note that the alignment check is required. It is possible that an atomic has stricter alignment requirements than the underlying type.

But this still has undefined behavior because std::atomic_ref requires that there won't be any access to the object through a non-std::atomic_ref as long as it lives. In other words, there are no memory ordering guarantees for accessing the same address through atomic and non-atomic lvalues at the same time.

Even if that was not the case however, there is no need to reload *pt after *pat. Assuming *pat read the result of a release-store which it then synchronizes with. The value obtained by reading *pt would need to be the same that *pat read, otherwise there would have been another store to the address in-between *pt and *pat which neither synchronize with and that would be a data race with undefined behavior.
With similar reasoning it would be valid to optimize away the first load of *pt as well.

Even if all the loads were atomic with memory_order_cst_seq the compiler would be permitted to optimize all but one of them away. Atomic operations are not volatile operations and do not count as observable behavior. A store from another thread should become visible to this thread in a timely manner, but it is fine for the compiler to assume that bounded sequence of instructions in this thread happens atomically with respect to that store if this is implementable. There is no guarantee that any possible interleaving of threads can be observed.

---

Please note that I am only explaining the semantics according to the standard, I do not know whether Clang intends to make any guarantees beyond that in this case.

[DoctorNoobingstoneIPresume]

Thank you for kind explanations !!