Basically, what the gcc developers are saying is that gcc isfree to load and store to any memory location, so long as itbehaves as if the instructions were executed in sequence.

I guess that dynamically allocated memory and computed pointersare more difficult for gcc to do anything unsafe with, becauseit is harder to tell if a given function has deallocated thememory. However even that could theoretically happen in futureif the compiler can work out the address comes from a globalvariable or is not changed intermediately.

Linux makes extensive use of both trylocks and interruptiblelocks (ie. which automatically result in divergant code paths,one of which holds the lock, the other doesn't). However thereare also other code paths which will either hold a particularlock or will not hold it, depending on context or some flagsetc. barrier() doesn't help.

For x86, obviously the example above shows it can be miscompiled,but it is probably relatively hard to make it happen for a nontrivial sequence. For an ISA with lots of predicated instructionslike ia64, it would seem to be much more likely. But of coursewe don't want even the possibility of failures.

The gcc guys seem to be saying to mark everything volatile thatcould be touched in a critical section. This is insane for Linux.