This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlinedastrees
- From: Jason Merrill <jason at redhat dot com>
- To: Paul Schlie <schlie at mediaone dot net>
- Cc: Linus Torvalds <torvalds at transmeta dot com>, Alexandre Oliva <aoliva at redhat dot com>, Richard Henderson <rth at redhat dot com>, <gdr at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 16 Dec 2001 19:43:19 +0000
- Subject: Re: Volatile MEMs in statement expressions and functions inlinedastrees
- References: <B8425FCC.3A5Cfirstname.lastname@example.org>
>>>>> "Paul" == Paul Schlie <email@example.com> writes:
>>>>>>> "Paul" == Paul Schlie <firstname.lastname@example.org> 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
> 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?
> But in no case should the interpretation be ambiguous, some uniform rule
> should be established.
>>> 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.