From: H. Peter Anvin on
I believe that's how it is actually implemented though, and I believe we'd have failures all over if that was not true.

"Jeremy Fitzhardinge" <jeremy(a)> wrote:

>On 07/13/2010 03:14 PM, H. Peter Anvin wrote:
>> Actually, I believe volatile operations (including asm volatile) are
>> strictly ordered *with respect to other volatile operations*.
>The documentation makes no reference to that property; in fact it
>suggests it is outright not true:
> Note that even a volatile `asm' instruction can be moved relative to
> other
> code, including across jump instructions. For example, on many targets
> there is a system register which can be set to control the rounding
> mode of floating point operations. You might try setting it with a
> volatile `asm', like this PowerPC example:
> asm volatile("mtfsf 255,%0" : : "f" (fpenv));
> sum = x + y;
> This will not work reliably, as the compiler may move the addition
> back before the volatile `asm'. To make it work you need to add an
> artificial dependency to the `asm' referencing a variable in the
> code you don't want moved, for example:
> asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
> sum = x + y;
> Similarly, you can't expect a sequence of volatile `asm'
> instructions to remain perfectly consecutive.
> [...]
> An `asm' instruction without any output operands will be treated
> identically to a volatile `asm' instruction.
>> As such I
>> would think we'd want to keep the "memory" clobber here, to make it
>> strictly ordered with regards to *all* memory operations.
>That would keep its overall effect consistent.
> J

Sent from my mobile phone. Please pardon any lack of formatting.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)
More majordomo info at
Please read the FAQ at