Re: Volatile MEMs in statement expressions and functions inlined astrees

[Jason Merrill <jason at redhat dot com>]

>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

> On Fri, 7 Dec 2001, Jason Merrill wrote:

>> > int bar, volatile *vpi;
>> > int foo = ({ *vpi = bar; });

>> I would handle this case identically.  It should be reloaded in C++, not in
>> C, and should really be written ({ *vpi = bar; bar; }).

> As mentioned, I disagree violently.

> Would you reload for the expression

> 	int bar, volatile *vpi;
> 	({ *vpi = bar; });

> which does all the same things, it just doesn't assign to "foo"?

That depends on the semantics of the GCC statement-expression extension.
I think that as currently implemented, the answer is yes.  No would also be
fine with me.

> And if you _would_ reload, would you do it for

> 	int bar, volatile *vpi;
> 	*vpi = bar;

> then?

No.

> And if the answer is no, as I think it very clearly is (for both C and
> C++), then why would assigning a totally unrelated variable change the
> behaviour of accesses through "vpi"?

Because of the lvalue-to-rvalue conversion necessary to extract an actual
integer from the lvalue result of the assignment.

> I've never heard of "assignment" having non-local behaviour that changes
> depending on whether you use the value of the assignment or not.

It has nothing to do with assignment, except that the builtin assignment
operator returns a reference; any other situation involving references
works the same way.  Extracting a value from a reference involves a load.
To write it another way, the C++ expression

  q = p = 0

is equivalent to the C expression

  q = *(p = 0, &p)

Should that not load from p?

Jason