This is the mail archive of the
mailing list for the GCC project.
RE: -fno-tree-cselim not working?
Dave Korn writes:
> On 26 October 2007 15:59, Ian Lance Taylor wrote:
> > Andreas Schwab <email@example.com> writes:
> >> Ian Lance Taylor <firstname.lastname@example.org> 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