This is the mail archive of the gcc-patches@gcc.gnu.org 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: [gimple] assignments to volatile


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


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