[gimple] assignments to volatile

Nathan Sidwell nathan@codesourcery.com
Tue Jun 22 13:54:00 GMT 2010


On 06/22/10 13:37, Michael Matz wrote:

>> I think these lead to confusing code sequences, and are not composable.
>> Fundamentally the ambiguity comes from specifying when an assignment's value
>> is needed.
>
> Indeed.  Both semantics (re-read or no re-read) will generate some
> surprises, mine has the problem of context dependency,

As this is the case then I think we're looking for the solution with the least 
surprise, and whatever solution we have will be outside the bounds of the std to 
some greater or lesser extent.

> yours for instance
> breaks this identity:
>    x = vol = y;
> <==>
>    vol = y;
>    x = vol;
>
> I read the standard as requiring this identity to hold (in particular the
> language about values of assignments not being lvalues is only to disallow
> constructs like "(a = b) = c;").

Thanks for identifying the crux of the difference.  I don't think that 
transformation is an identity when volatiles are in play.  Volatile objects 
break all sorts of transformations that would otherwise be fine.  For instance 
your semantics make the following transform not an identity:
    tmp = vol;
    // no further use of tmp
<==>
    vol;

I don't see what's special about the transformation you're highlighting as not 
being an identity under one set of semantics.

I'm still having a problem with sequence points.  Your email of yesterday:

 > Now, onto 6.5 #2:
 >
 >    Between the previous and next sequence point an object shall have its
 >    stored value modified at most once by the evaluation of an expression.
 >    Furthermore, the prior value shall be read only to determine the value
 >    to be stored.70)
 >
 > This talks only about the side-effect of changing the stored value (which
 > we do only once) and about the prior value, which we don't use at all.

I had misremembered that piece of the std as saying 'the object's value shall be 
read only ...'.  I.e. no 'prior' in there.  Indeed, the explanation given in the 
C-faq http://linuxdude.com/Steve_Sumit/C-faq/q3.8.html is 'any and all accesses 
to it within the same expression must be for the purposes of computing the value 
to be written'.  I did think the mental model I have of assignments came from 
the C-faq, but I can't find it there.  Here it is, perhaps someone will 
recognize the author?

1) for each assignment, the new value is written on a ball, and thrown at the 
lvalue target.

2) it is guaranteed all balls will arrive at their targets by the next sequence 
point.

3) if more than one ball is aimed at the same target, chaos occurs.

4) if you try and read a target when a ball is in flight for that target, chaos 
occurs.

Your read-after-write interpretation breaks that model (of course the model 
could be wrong)

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery



More information about the Gcc-patches mailing list