RE: -fno-tree-cselim not working?

[Andrew Haley <aph-gcc at littlepinkcloud dot COM>]

Dave Korn writes:
 > On 26 October 2007 15:59, Ian Lance Taylor wrote:
 > 
 > > Andreas Schwab <schwab@suse.de> writes:
 > > 
 > >> Ian Lance Taylor <iant@google.com> writes:
 > >> 
 > >>> The above code happens to use pthread_mutex_trylock, but there is no
 > >>> need for that.
 > >> 
 > >> pthread_mutex_trylock is special, because POSIX says it is a memory
 > >> synchronisation point (see section 4.10 Memory Synchronization).
 > > 
 > > Sure.  But the argument that gcc is doing something wrong stands up
 > > just fine even we just test a global variable.  The argument that gcc
 > > is doing something wrong does not rely on the fact that the function
 > > called is pthread_mutex_trylock.
 > 
 >   Indeed; as I understand it, what the argument that gcc is doing
 > something wrong relies on is the incorrect assumption that *all*
 > variables ought to behave like volatile ones, i.e. have an exact
 > one-to-one relationship between loads and stores as written in the
 > HLL and actual machine load/store operations.

No, it doesn't, it relies on the fact that POSIX allows shared access
to non-volatile memory as long as mutexes are used to enforce mutual
exclusion.  POSIX does not require memory used in such a way to be
declared volatile.  The problem with your argument is that you're
looking at ISO C but not at POSIX threads.

The new C++ threads memory model is intended by its authors to solve
this mess.

Andrew.