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 astrees
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: Gabriel Dos Reis <gdr at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 14 Dec 2001 11:14:49 -0800 (PST)
- Subject: Re: Volatile MEMs in statement expressions and functions inlined astrees
On 14 Dec 2001, Alexandre Oliva wrote:
> On Dec 14, 2001, Linus Torvalds <torvalds@transmeta.com> wrote:
>
> > The fact is, C++ does NOT "create" addresses for true rvalues.
>
> Guess what: it does.
Not in general.
There are "gray areas", but rvalues in general do not have addresses, and
the compiler will _not_ generate them. I already gave the simple example
of the obvious "pp = &(p+1)" etc.
Does C++ have some magic special cases? It sure as hell does. But you
cannot create an address for most rvalues: no compiler is able to create a
valid address for simple expressions etc.
In particular, C++ structure return is implemented as an implied "call by
reference" where the _caller_ will pass the callee a temporary variable
that does not actually exist on a source level, and the callee will return
the value in that variable (not "that" - "this").
Now, that return value is not really an lvalue, but it's actually
addressable by the compiler in the caller, because of the implied temp
variable. At least that's how I understand it (and I'll freely admit that
my understanding of all the magic C++ behaviour is very very limited: it's
a rather complex language).
COULD it be a real lvalue? Yes. I think that special case is actually a
syntactic one, not a fundamental issue. Not making that addressable
variable a lvalue means that the compiler on a syntactic level actually
disallows you from taking the address of the temporary object.
(I actually _did_ mention the magic C++ "pass by reference" in my email,
see the last incoherent comments on lvalue vs rvalue).
Linus