This is the mail archive of the gcc@gcc.gnu.org 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?


On 10/26/07, Andrew Haley <aph-gcc@littlepinkcloud.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)
>     counter++;
>
> 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.

Richard.


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