On 14 Mar 2006, at 10:40, Jan Beulich wrote:
Won't this need a barrier() (compile barrier) between the updates of
low and high portions?
No, I can't see why. The compiler isn't permitted to re-order separate
writes across
sequence points (which is different from a single 64-bit write, where
the compiler is
only expected to carry out the full 64-bit write prior to the next
sequence point, but
nothing requires it to do this in any particular order).
The compiler is certainly allowed to reorder those updates. The
constraints on a conforming implementation of C99 are pretty weak, and
don't say anything about obeying the rules for access/update ordering
on non-volatile objects. Whether gcc reorders such updates is another
matter. :-)
If I build the following with -O2 on x86/64 gcc 4.1, the compiler
removes the first update of x. If I take a signal after the update of
y, the signal handler can see y==2, z!=2 but also x!=2, which disobeys
the semantics of the C99 abstract machine semantics:
int x, y, z;
void foo(void) { x = 2; y = 2; z = 2; x = 0; }
Really it's safer just to include the barrier(), and makes our ordering
requirement explicit in the code.
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home