Rrerku

Is the behavior of this code well-defined?

#include <stdatomic.h>

const int test = 42;
const int * _Atomic atomic_int_ptr;
atomic_init(&atomic_int_ptr, &test);
const int ** int_ptr_ptr = &atomic_int_ptr;
printf("int = %dn", **int_ptr_ptr); //prints int = 42

I assigned a pointer to atomic type to a pointer to non-atomic type (the types are the same). Here are my thoughts of this example:

The Standard explicitly specify distinction of const, volatile and restrict qualifiers from the _Atomic qualifier 6.2.5(p27):

this Standard explicitly uses the phrase ‘‘atomic, qualified or
unqualified type’’ whenever the atomic version of a type is permitted
along with the other qualified versions of a type. The phrase
‘‘qualified or unqualified type’’, without specific mention of atomic,
does not include the atomic types.

Also the compatibility of qualified types is defined as 6.7.3(p10):

For two qualified types to be compatible, both shall have the
identically qualified versionof a compatible type; the order of
type qualifiers within a list of specifiers or qualifiers does
not affect the specified type.

Combining the quotes cited above I concluded that atomic and non-atomic types are compatible types. So, applying the rule of simple assigning 6.5.16.1(p1) (emp. mine):

the left operand has atomic, qualified, or unqualified pointer
type, and (considering the type the left operand would have
after lvalue conversion) both operands are pointers to qualified
or unqualified versions of compatible types, and the type pointed to by
the left has all the qualifiers of the type pointed to by the right;

So I concluded that the behavior is well defined (even in spite of assigning atomic type to a non-atomic type).

The problem with all that is that applying the rules above we can also conclude that simple assignment a non-atomic type to an atomic type is also well defined which is obviously not true since we have a dedicated generic atomic_store function for that.

6.2.5p27:

Further, there is the _Atomic qualifier. The presence of the _Atomic
qualifier designates an atomic type. The size, representation, and
alignment of an atomic type need not be the same as those of the
corresponding unqualified type. Therefore, this Standard explicitly
uses the phrase ''atomic, qualified or unqualified type'' whenever the
atomic version of a type is permitted along with the other qualified
versions of a type. The phrase ''qualified or unqualified type'',
without specific mention of atomic, does not include the atomic types.

I think this should make it clear that atomic-qualified types are not deemed compatible with qualified or unqualified versions of the types they're based on.

I C11 allows _Atomic T to have a different size and layout than T, e.g. if it's not lock-free. (See @PSkocik's answer). And also alignof(T) !=alignof(_Atomic T)`, but that's not an issue for casting pointers to objects that already exist.

For example, the implementation could choose to put a mutex inside each atomic object, and put it first. (Instead of the usual using the address as an index into a table of locks: Where is the lock for a std::atomic?).

Therefore _Atomic T* is not compatible with T* even in a single-threaded program.

Merely assigning a pointer might not be UB (sorry I didn't put on my language lawyer hat), but dereferencing certainly must be.

(In practice on real implementations, _Atomic T* and T* use the same object representation, and a single-threaded or mutex-guarded part of a program could do non-atomic access to an _Atomic object.)

The problem with all that is that applying the rules above we can also conclude that simple assignment a non-atomic type to an atomic type is also well defined which is obviously not true since we have a dedicated generic atomic_store function for that.

No, that reasoning is flawed.

atomic_store(&my_atomic, 1) is equivalent to my_atomic=1; They both do an atomic store with memory_order_seq_cst. You can see this from looking at the code-gen for real compilers, e.g. x86 compilers will use an xchg instruction, or mov+mfence. Similarly, shared_var++ compiles to an atomic RMW (with mo_seq_cst).

IDK why there's an atomic_store generic function. Maybe just for contrast / consistency with atomic_store_explicit, which lets you do atomic_store_explicit(&shared_var, 1, memory_order_release) or memory_order_relaxed to do a release or relaxed store instead of sequential-release. (On x86, just a plain store. Or on weakly-ordered ISAs, some fencing but not a full barrier.)

For types that are lock-free, where the object representation of _Atomic T and T are identical, there's no problem in practice accessing an atomic object through a non-atomic pointer in a single-threaded program. I suspect it's still UB, though.

C++20 is planning to introduce std::atomic_ref<T> which will let you do atomic operations on a non-atomic variable. (With no UB as long as no threads are potentially doing non-atomic access to it during the time window of being written.) This is basically a wrapper around the __atomic_* builtins in GCC for example, that std::atomic<T> is implemented on top of. (This presents some problems, like if atomic<T> needs more alignment than T, e.g. for long long or double on i386 System V. Or a struct of 2x int on most 64-bit ISAs.)

Anyway, I'm not aware of any standards-compliant way to do similar things in portable ISO C11, but it's worth mentioning that real C compilers very much do support doing atomic operations on objects declared without _Atomic. But only using stuff like GNU C atomic builtins.:

See Casting pointers to _Atomic pointers and _Atomic sizes : apparently casting a T* to _Atomic T* is not recommended even in GNU C. Although we don't have a definitive answer that it's actually UB.