This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: -fno-tree-cselim not working?

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.

gcc turns this code into

  tmp = counter;
  if (we_hold_the_counters_mutex)
  counter = tmp;

This introduces a data race that is not in the user's program.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]