__ATOMIC_RELAXED and cache coherency

[Victor <victor at enise dot org>]

Hello!

Could someone please explain the following details about
`__ATOMIC_RELAXED`?

--------
Q1

If thread `A` performs an atomic store with relaxed memory order, and
*after that* thread `B` performs an atomic load with relaxed memory
order, is it guaranteed that `B` gets actual value, on all
architectures supported by GCC?

--------
Q2

From GCC wiki: https://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync

> There is also the presumption that relaxed stores from one thread are
> seen by relaxed loads in another thread within a reasonable amount of
> time. That means that on non-cache-coherent architectures, relaxed
> operations need to flush the cache (although these flushes can be
> merged across several relaxed operations)

 2.1 I can't it figure out, does this mean that GCC will generate a
     cache flush, if necessary, or should I flush it by myself?

 2.2 What is the actual list of those non-cache-coherent architectures,
     supported by GCC?

--------
Q3

On what architectures GCC will generate different code for
`__atomic_load(__ATOMIC_RELAXED)` and usual read of `volatile` variable?

I've tried these examples:

 E1.

    volatile int data;

    int main() {
        data;
        return 0;
    }

 E2.

    volatile int data;

    int main() {
        __atomic_load_n(&data, __ATOMIC_RELAXED);
        return 0;
    }

For x86/64, arm (arm-none-eabi-gcc w/o addition options), and mipsel
(mipsel-linux-gnu-gcc w/o addition options), GCC generates identical
code for both examples.

-- Victor