On Tue Feb 17, 2026 at 4:32 PM GMT, Linus Torvalds wrote:

On Tue, 17 Feb 2026 at 08:23, Linus Torvalds
[off-list ref] wrote:

quoted

But last time I looked at it - which was admittedly a few years ago -
the compilers we supported didn't actually do anything reasonable here
(ie the built-in atomics were fundamentally worse than the ones we do
by hand, and even basic things like __atomic_load_n() weren't
actually; better than just using 'volatile'.

Maybe that has changed. We've upgraded minimum compilers since.

I  just checked a few test-cases, and I don't think anything has changed.

All the trivial things where __atomic_load_n(__ATOMIC_RELAXED) *could*
do better than just our old code using "cast pointer to volatile"
resulted in no better code generation.

I think compilers are *very* conservative in implementing any optimization
related to atomics, to the extent that normal atomics load/stores are
effectively volatile atomic load/stores and thus the optimization you are
referring to here does not get performed.

However there is some limited optimizations being done to fences, at least I
know in LLVM multiple fences do get merged.

E.g. if you have 

    atomic_thread_fence(memory_order_acquire);
    atomic_thread_fence(memory_order_acq_rel);

the first fence is abosrbed into the second.

So we're sticking to that "cast to volatile" not because it's great,
but because it continues to be reliable and no worse than the fancy
modern versions.

But at least it's explicit in the code, not hidden away in code that
*looks* like it just dereferences another field in a structure.

The implicit load/store is arguably the biggest design failure of C11 atomics.
However we can still typedef like atomic_t or use "cast to _Atomic". But as you
said, currently this does not really yield any benefits over "cast to volatile".

Best,
Gary