This is the mail archive of the
mailing list for the GCC project.
Re: -fno-tree-cselim not working?
On 10/26/07, Andrew Haley <email@example.com> wrote:
> Dave Korn writes:
> > On 26 October 2007 16:27, Andrew Haley wrote:
> > > Dave Korn writes:
> > > > On 26 October 2007 15:59, Ian Lance Taylor wrote:
> > > > > 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.
> > Perhaps I've jumped into the wrong one of the two near-identical
> > threads we have going on this, but my understanding of the original
> > complaint was that gcc writes to the variable regardless of whether
> > it needs an update or not, and that this is a problem in the case
> > where one thread is accessing *without* using the mutex that the
> > other one *is* using.
> No, that is not the problem.
> The problem is code like this:
> int counter;
> if (we_hold_counters_mutex)
> This is legal POSIX threads code: counter is not accessed when we do
> not hold the mutex. According to POSIX we do not have to declare
> volatile memory that we only access when we hold a mutex.
I hope we're not trying to support such w/o volatile counter. Whatever
POSIX says, this would pessimize generic code too much.