Re: [RFC/PATCH] doc: volatile considered evil

[David Rientjes <rientjes@google.com>]

On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:

> It's probably worth noting that "asm volatile (...)" doesn't mean what
> many people think it means: specifically, it *does not* prevent the asm
> from being reordered with respect to the surrounding code.  It may not
> even prevent it from being reordered with respect to other asm
> volatiles.  *All* it means is that the asm code will be emitted even if
> the compiler doesn't think its results will be used.  Note that an
> "asm()" with no outputs is implicitly "asm volatile()" - on the grounds
> that it would be otherwise useless as far as gcc can tell.
> 
> If you need to guarantee ordering of asm statements, you must do it
> explicitly, with either a "memory" clobber, or some finer-grain
> serialization variable (like the _proxy_pda stuff).  It would be useful
> if you could tell gcc "I'm passing this variable to the asm for
> serialization purposes, but there's no need to generate any explicit
> references to it", but as far as I know there's no support for that.
> 

Ok, so let's take your second paragraph and my email of an hour ago:

	In an asm construct, if all your input operands are modified and 
	specified as output operands as well, volatile must be added so 
	that the entire construct is not optimized away.  Additionally, 
	it must be added if your construct modifies memory that is neither 
	listed in inputs nor outputs to the construct so that it is known 
	to have at least one side-effect.  Then, the compiler cannot 
	delete your construct if it is reachable because it may produce 
	such side-effects.

and add it to any proposed change to CodingStyle that suggests against the 
'volatile' keyword since there exists a distinct difference in behavior 
between using the keyword as a type qualifier for an object and as a 
qualifier for an asm construct.

		David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/