Re: [PATCH] i386 linux: make 32-bit PAE kernel work when built with newer gcc

["Jan Beulich" <JBeulich@novell.com>]

>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. :-)

I'm not sure this is correct - the standard, in section 5.1.2.3, says

"Accessing a volatile object, modifying an object, modifying a file, or calling a function
that does any of those operations are all side effects, which are changes in the state of
the execution environment. Evaluation of an expression may produce side effects. At
certain specified points in the execution sequence called sequence points, all side effects
of previous evaluations shall be complete and no side effects of subsequent evaluations
shall have taken place."

As we're talking about modifying an object, this being considered a side-effect means it
must have been carried out by the time the ; is (logically) reached.

>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; }

I believe it doing so is permitted by the fact that a signal here can only come from outside of
the program (the compiler can prove that none of these accesses can fault, at least not in
the sense the program cares about), and the standard doesn't care about 'outside'. If you
inserted a function call after the update to y, I'm sure the compiler would leave the first
write to x.

>Really it's safer just to include the barrier(), and makes our ordering 
>requirement explicit in the code.

It might still be safer, I agree, to prevent broken compiler versions to do bad.

Jan