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

[Martin Sebor]

> I intend to use the ATOMIC macro only in the normal code (as in the ISR, interrupts are disabled anyway).
> Thanks for confirming that I don't need a barrier in the ISR.

I didn't say a barrier in the ISR wasn't necessary, just that
it's not sufficient for this particular use case. (A compiler
barrier obviously is necessary to prevent the code motion you
are concerned about.)

>
>> isn't volatile the normal code may never see its value change.
> My use case is a bit different - I only read the array after the barrier, when the pointers into the array are updated. So, before the barrier, in the source code, there is no read from the array into registers which could then be used by the compiler to avoid another read later.
> But, without declaring the array volatile, how can I avoid that the compiler puts the read speculatively ahead of the barrier and, as soon as it knows the address, uses that to choose the right register - admittedly, this doesn't make sense on AVR. But how do I KNOW the compiler wont do such a thing on an architecture where a cache needs to be filled?

I can't think of a more appropriate solution that using volatile.

Let me clarify one important property of the GCC implementation.
In contrast to a strict reading of the C standard, GCC doesn't
require an object to be declared volatile in order to guarantee
that volatile semantics are applied to accesses to it. What
matters is the volatility of the lvalue used to perform the
access.

With that in mind, the buffer array can safely be declared
non-volatile as long as all accesses to it that need volatile
semantics are via a pointers to a volatile-qualified type (such
as one of the two pointers below):

   char buffer[ARRAY_SIZE];

   volatile char* volatile volatile_read_pointer = buffer;
   volatile char* volatile volatile_write_pointer = buffer;

Functions that don't need the volatile semantics can use the
buffer directly or via non-volatile pointers.

Martin