Re: Volatile MEMs in statement expressions and functions inlinedastrees

[Paul Schlie <schlie at mediaone dot net>]

>>>>>> "Paul" == Paul Schlie <schlie@mediaone.net> writes:
> 
>> (tt)(lv = rv) :: (lv = ((lt)tmp = rv, (lt)tmp), (tt)((lt)tmp))
> 
> Nope.  If this was the case, then (x += y) += z would add z to some random
> temporary.
> 

Would have expected it to unambiguously be equivalent to:

 x = x + y, x = x + z;

Yielding first:
- two potentially unoptimizable volatile read references of x and y in
undefined order, followed by a potentially unoptimizable volatile store to
x;

Followed by:
- two potentially unoptimizable volatile read references of x and z in an
undefined order, followed by a potentially unoptimizable volatile store to
x;

Or if one were to impose a refining rule that: only as many load/store
references may occur to volatile variables as explicit references to those
variables exist in the originating source code, yielding:

 x = (x + y) + z;

But in no case should the interpretation be ambiguous, some uniform rule
should be established.

<snip>

>> And it is agreed that:
> 
>>  volatile q
>>  (q = 10) == 10
> 
> No, that's where I disagree.
> 
> As Alexandre says, if you want to interact with hardware interfaces, do it
> with simple assignments.
> 
> Jason

It it being asserted that:

 volatile q
 (q = 10) == 10

is ambiguous, and therefore defined?