RE: -fno-tree-cselim not working?

[Andrew Haley <aph-gcc at littlepinkcloud dot COM>]

Dave Korn writes:
 > On 26 October 2007 17:11, Andrew Haley wrote:
 > 
 > >  >   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. 
 > 
 >   Well, that's the bone of contention.  I suggest that you cannot
 > infer "counter is not accessed" when the condition is false,
 > according to the C language spec, because there are two different
 > semantics of the word "accessed" here: as-if accessed, as per the
 > ideal machine definition of C, and actually accessed, as in what
 > actually happens in the underlying code.  The C standard only makes
 > guarantees about the as-if accesses.

That's right: the problem is that POSIX threads makes assumptions that
the C standard does not guarantee.  This is why I said previously "The
problem with your argument is that you're looking at ISO C but not at
POSIX threads."  POSIX threads requires more than just strict ISO
as-if semantics.

 > > According to POSIX we do not have to declare
 > > volatile memory that we only access when we hold a mutex.
 > 
 >   Is the problem that POSIX doesn't make the distinction between
 > as-if and actual behaviour that is such an essential part of the C
 > standard?

POSIX introduces extra requirements that are not part of the C
standard.  This is one of them.  Unfortunately it does so in a
more-or-less informal way.

 > > This introduces a data race that is not in the user's program.
 > 
 >   Do you mean that it's not in the as-if idealised version of the
 > program that the compiler constructs, or that it's not in the
 > high-level source?

The program actually requires not just Standard C but Standard C +
POSIX threads.  In other words, you cannot optimize POSIX threads
programs in the same way that you optimize single-threaded progarms.
This argument is the subject of Hans Boehm's paper "Threads cannot be
implemented as a library", referenced above.

Andrew.