Re: [patch] fix pre-/post- in-/decrement

[Daniel Jacobowitz <dan at codesourcery dot com>]

On Tue, Oct 05, 2010 at 03:28:19PM +0200, Ulrich Weigand wrote:
> Daniel Jacobowitz wrote:
> > On Tue, Oct 05, 2010 at 01:24:51AM +0200, Ulrich Weigand wrote:
> > > - If you execute "set *$p = *$q = 0" and the write to *$q fails,
> > >   do you really expect *$p to be set to the old value of *$q
> > >   instead of to 0?
> > 
> > Yes, I would expect that.  To me, this is roughly "the debugger treats
> > all pointers as volatile".
> 
> The thing is, I had interpreted the C standard to read that even if
> pointers p and q *are* volatile, a statement like "*p = *q = 0" would
> still just trigger two writes, and no reads.

You're right, I remember Nathan's recent arguments about this on
gcc-patches.

> "Assignments are also expressions and have an rvalue. However when assigning
> to a scalar volatile, the volatile object is not reread, regardless of whether
> the assignment expression's rvalue is used or not. If the assignment's rvalue
> is used, the value is that assigned to the volatile object. [...]  If you need
> to read the volatile object after an assignment has occurred, you must use a
> separate expression with an intervening sequence point."

> To reduce the potential for confusion, it seems to me GDB ought to mirror
> that behavior as well ...

Hmm.

It seems to me that this is a disruptive change for us, because the "a
= b" case is more likely to be used than anything fancy (a += b, a = b
= c).  If we change it, we should document the change.

Vladimir, would this interact with your recent varobj changes?  We
worked out exactly which reads we wanted, but I don't remember if
value_assign is involved.

-- 
Daniel Jacobowitz
CodeSourcery