This is the mail archive of the
mailing list for the GCC project.
RE: -fno-tree-cselim not working?
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
> > 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
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.