This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlined as trees
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Gabriel Dos Reis <gdr at codesourcery dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 13 Dec 2001 12:50:57 -0800 (PST)
- Subject: Re: Volatile MEMs in statement expressions and functions inlined as trees
On 13 Dec 2001, Gabriel Dos Reis wrote:
> Linus Torvalds <email@example.com> writes:
> | In short: we convert that lvalue to a rvalue, because the expression has a
> | value WHETHER IT IS USED OR NOT.
> If the standard say the expression is an lvalue, on what basis shoulc
> GCC/g++ decide to convert it to an rvalue?
All expressions have a value that they return.
That value is the rvalue.
The fact that the expression is an lvalue doesn't change that.
Being an lvalue means that you can do _more_ with an expression, both in C
and C++. But it's still an expression.
I repeat: try this little experiment with your C++ compiler:
volatile int p;
and compile it with "g++ -O2 -S test.cpp", and look at the output that gcc
Why is that load off "p" there in the assembly output? It's there because
yes, "p" is an lvalue, but "p" is _also_ an expression that has a value,
and that value is gotten through loading from p. That _value_ is not a
lvalue - it's the rvalue that is associated with the lvalue that is "p".
And note how we still loaded it, even though the rvalue wasn't actually
How do you reconcile this _fact_ with your rules?
Face it, you've completely made up your rules, and they are _not_
supported by either current gcc behaviour or by the standards text.