RE: -fno-tree-cselim not working?

["Dave Korn" <dave dot korn at artimi dot com>]

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.  The false assumption is that
the code sequence "if (cond) var = value" will only touch var if cond is true
- this assumption is only valid for volatile variables.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....