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?

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.

  We need to take more care in this discussion to be clear about which sense
of the word "access" we mean at any time, otherwise anything we say is going
to be underdefined and ambiguous.

> 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?

> gcc turns this code into
>   tmp = counter;
>   if (we_hold_the_counters_mutex)
>     tmp++;
>   counter = tmp;

  Yes, I understand that perfectly well.  That is actually what I described in
my first quoted paragraph above - but I was referring to /actually/ accessed,
not /as-if/ accessed.

> 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?  A

Can't think of a witty .sigline today....

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