This is the mail archive of the 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 inlined as trees

On 13 Dec 2001, Gabriel Dos Reis wrote:
> Linus Torvalds <> writes:
> | In short: we convert that lvalue to a rvalue, because the expression has a
> 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;

	void test(void)

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.


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