This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Heads-up: volatile and C++
I'm including the standard annotations, they have no standard
value but sometimes do help.
Laurent
C.6 Shared Variable Control
Dynamic Semantics
15 For an atomic object (including an atomic component) all reads and
updates of the object as a whole are indivisible.
16 For a volatile object all reads and updates of the object as a whole are
performed directly to memory.
16.a Implementation Note: This precludes any use of register temporaries,
caches, and other similar optimizations for that object.
17 {sequential (actions)} Two actions are sequential (see 9.10) if each is
the read or update of the same atomic object.
18 {by-reference type (atomic or volatile) [partial]} If a type is atomic
or volatile and it is not a by-copy type, then the type is defined to be a
by-reference type. If any subcomponent of a type is atomic or volatile, then
the type is defined to be a by-reference type.
19 If an actual parameter is atomic or volatile, and the corresponding
formal parameter is not, then the parameter is passed by copy.
19.a Implementation Note: Note that in the case where such a parameter is
normally passed by reference, a copy of the actual will have to be
produced at the call-site, and a pointer to the copy passed to the
formal parameter. If the actual is atomic, any copying has to use
indivisible read on the way in, and indivisible write on the way
out.
19.b Reason: It has to be known at compile time whether an atomic or a
volatile parameter is to be passed by copy or by reference. For some
types, it is unspecified whether parameters are passed by copy or by
reference. The above rules further specify the parameter passing
rules involving atomic and volatile types and objects.
Implementation Requirements
20 {external effect (volatile/atomic objects) [partial]} The external
effect of a program (see 1.1.3) is defined to include each read and update of
a volatile or atomic object. The implementation shall not generate any memory
reads or updates of atomic or volatile objects other than those specified by
the program.
20.a Discussion: The presumption is that volatile or atomic objects might
reside in an ``active'' part of the address space where each read
has a potential side-effect, and at the very least might deliver a
different value.
20.b The rule above and the definition of external effect are intended to
prevent (at least) the following incorrect optimizations, where V is
a volatile variable:
20.c X:= V; Y:=V; cannot be allowed to be translated as Y:=V; X:=V;
20.d Deleting redundant loads: X:= V; X:= V; shall read the value of V
from memory twice.
20.e Deleting redundant stores: V:= X; V:= X; shall write into V twice.
20.f Extra stores: V:= X+Y; should not translate to something like V:= X;
V:= V+Y;
20.g Extra loads: X:= V; Y:= X+Z; X:=X+B; should not translate to
something like Y:= V+Z; X:= V+B;
20.h Reordering of loads from volatile variables: X:= V1; Y:= V2;
(whether or not V1 = V2) should not translate to Y:= V2; X:= V1;
20.i Reordering of stores to volatile variables: V1:= X; V2:= X; should
not translate to V2:=X; V1:= X;