Are arrays guaranteed to be affected by a "memory" clobber?

[Andrew Haley]

On 11/06/15 22:38, Sebastian wrote:
> On Thu, 11 Jun 2015 12:21:23 +0100
> Andrew Haley <aph@redhat.com> wrote:
> 
>> I'd use a full memory barrier.  __sync_synchronize() 
> Isn't __sync_synchronize() the same as a memory clobber + hardware barrier?

It's a compiler barrier and a hardware barrier.  If you processor has
no hardware barriers, then it's just a compiler barrier.  It does the
right thing either way.

>> this guarantees that no memory operations will not
>> be moved  across the barrier.

> Still the open question: Is access to array elements (or
> dereferencing a pointer) always considered a "memory operation",

Yes.

> unlike the variable access in the example in [2]?

Eh?  The vriable access is a memory operation in [2].  It is
surrounded by the cli/sei, as required.  We cannot guarantee that
non-memory operations will not be reordered with memory barriers,
though.

>> or one of the __atomic fences.
> As far as I can see, you can only use them on integers or pointers,
> but not on arrays.

This makes no sense.  A fence is a fence.  It is not attached to any memory
location.  No memory access can move across it.

> So you think it would be enough to do the pointer manipulations
> atomically, and then the array accesses which depend on these
> pointers should be ok? That's what I'm thinking, too, but what I'm
> not sure about...

This makes no sense either.

Andrew.