Dave Korn wrote: > Andrew Haley wrote: >> Dave Korn wrote: >> >>> Adding a "memory" clobber to the inline asm works around the problem, >>> causing 4.3 series to generate the same assembly as head, but I think it's a >>> sledgehammer approach. Am I asking too much of GCC to not sink the store, >>> or >>> is 4.3 doing something wrong? I /think/ that the fact that there's a >>> volatile >>> store in ilockcmpexch means the earlier store shouldn't be moved past it, >>> and >>> that GCC is perhaps missing that the asm's output operand effectively >>> represents a volatile write through *t, but I could be misunderstanding the >>> rules about volatile. Anyone got their language lawyer's hat on at the >>> moment? >> You could just look at the standard, y'know. > > I did but I get as far as all that stuff about "The party of the third part > shall be known herein as the party of the third part" and find it very > difficult to know whether what it looks like it says actually is what it is > trying to say.
It's just a matter of learning the language in which it's written, and that's like learning a programming language. If you look at 6.7.3 Para 6 it says "... An object that has volatile-qualified type may be modified in ways unknown to the implementation or have other unknown side effects. Therefore any expression referring to such an object shall be evaluated strictly according to the rules of the abstract machine, as described in 5.1.2.3. Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously..." Now, this is admittedly gobbledygook, but it's important to note that it only says that volatile stores may not be moved across sequence points. It does *not* say that other stores may not be moved across volatile stores, which is what you were hoping for. We already discussed this subject before: see http://gcc.gnu.org/ml/gcc/2007-10/msg00477.html and the very long thread that followed. >> Volatile stores only block other volatile stores: they don't block >> *all* stores. If you really want a complete memory barrier, which >> in a mutex you surely do, then you're going to have to clobber >> memory. > > Ah. That suggests that HEAD is in fact _missing_ an optimisation > that 4.3 gets right. Maybe I should file a PR after all. Maybe. Andrew.
