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 inlined as trees



On 13 Dec 2001, Gabriel Dos Reis wrote:
> Linus Torvalds <torvalds@transmeta.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;

	void test(void)
	{
		p;
	}

and compile it with "g++ -O2 -S test.cpp", and look at the output that gcc
produces.

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".

Agreed?

And note how we still loaded it, even though the rvalue wasn't actually
used.

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.

			Linus


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