This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlined as trees
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: Linus Torvalds <torvalds at transmeta dot com>
- Cc: Gabriel Dos Reis <gdr at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: 13 Dec 2001 22:08:21 +0100
- Subject: Re: Volatile MEMs in statement expressions and functions inlined as trees
- Organization: CodeSourcery, LLC
- References: <Pine.LNX.4.33.0112131244360.1851-100000@penguin.transmeta.com>
Linus Torvalds <torvalds@transmeta.com> writes:
| 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.
>From C++ definition:
3.10/4
[Note: some built-in operators expect lvalue operands. [Example:
built-in assignment operators all expect their left hand operands to
be lvalues. ] Other built-in operators yield rvalues, and some
expect them. [Example: the unary and binary + operators expect
rvalue arguments and yield rvalue results. ] The discus-sion of each
built-in operator in clause 5 indicates whether it expects lvalue
operands and whether it yields an lvalue. ]
| The fact that the expression is an lvalue doesn't change that.
It does.
-- Gaby