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: Volatile MEMs in statement expressions and functions inlinedastrees


(sorry, final logical sequence annotations now included below)

> (please see annotations below)
> 
>>>>>>> "Paul" == Paul Schlie <schlie@mediaone.net> writes:
>> 
>>>>>>>>> "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;
>> 
>> As would I.  Actually, I should have said '(x = y) += z'; based on your
>> transformation above, I would expect this to become
>> 
>> tmp = y, x = tmp, tmp = tmp + z
>> 
>> whereas it should be
>> 
>> x = y, x = x + z
>> 
>> or am I misinterpreting you?
> 
> In which case I would re-write it as:
> 
> x = y, x = x + z
> 
> :: x = (x = ((xt)tmp = y, (xt)tmp)), ((xt)tmp2 = x, (xt)tmp2)
>                                   + ((xt)tmp3 = y, (xt)tmp3))

Logically: tmp = y, x = tmp, tmp2 = x, tmp3 = y, x = tmp2 + tem3

> 
> -or-
> 
> x = y + z
> 
> :: x = ((xt)tmp = y, (xt)tmp) + ((xt)temp2 = z, (xt)tmp2)
> 

 Logically: tmp = y, tmp2 = z, x = tmp + tmp2

> Depending on adherence to an abstract rule requiring correlation between
> the number and sequence of explicit original coded references to a volatile
> within an expression, to it's correspondingly more restrictive semantic
> interpretation.
> 
>> 
>>> But in no case should the interpretation be ambiguous, some uniform rule
>>> should be established.
>> 
>> Agreed.
>> 
>>>>> And it is agreed that:
>>>> 
>>>>> volatile q
>>>>> (q = 10) == 10
>>>> 
>>>> No, that's where I disagree.
>> 
>>> It it being asserted that:
>> 
>>>  volatile q
>>>  (q = 10) == 10
>> 
>>> is ambiguous, and therefore defined?
>> 
>> I am asserting that in C++ the above is unambiguously equivalent to
>> 
>> q = 10, q == 10
>> 
>> and therefore the result of the comparison cannot be predicted.
>> 
>> Jason
> 
> Hence you are asserting that "(q = 10) == 10" may not be true, if q is
> volatile. Correct?
> 
> -paul-


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