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: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: Linus Torvalds <torvalds at transmeta dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Gabriel Dos Reis <gdr at codesourcery dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: 14 Dec 2001 10:28:08 +0100
- Subject: Re: Volatile MEMs in statement expressions and functions inlined as trees
- Organization: CodeSourcery, LLC
- References: <Pine.LNX.firstname.lastname@example.org>
Linus Torvalds <email@example.com> writes:
| Think about this conceptually for a moment.
| What is the _fundamental_ property of an assignment from a hardware
| standpoint? You have two things: you have the address to be assigned, and
| you have the value.
| The _address_ is the "lvalue". Yes, I know, neither C nor C++ really
| _speak_ of lvalues in those terms, because both languages try to create a
| higher-level abstraction, but down-to-earth, thats' really what it is.
| And the "value" is the "rvalue".
Then how do you reconcile your position with the fact that you can
have the adress of an rvalue in C++?
| The "rvalue" of an assignment expression is the value stored.
Nobody is disputing that.
| And the the "lvalue" of an assignment expression is basically the address
| stored to (well, an "lvalue" is more than just the pointer - it's really
| the access that goes _with_ the pointer).
Nobody is disputing that also -- see my first posting.
| And I think Gabriel will hate this distinction
No, I do not hate that distinction. It is your conclusion that I do
not agree with.
| And I'm claiming that assignments are "different" - instead of
| dereferencing the lvalue to get the rvalue, we know the rvalue a priori,
| and we _set_ the lvalue to the rvalue.
So my question is: What do you think assigments expect on the
right-hand operand? An lvalue, an rvalue?
| If you think of lvalue/rvalue this way, then there is no inherent conflict
| between "having the value stored" and "being an lvalue".
| Basically, the expression
| p = 0;
| really gets split up into tho "threads" - what is the lvalue of the
| expression, and what is it's rvalue? The two are _different_.
| expression lvalue rvalue side effect
| p 'p *&p -
| p = x 'p x store rvalue into p
| &p - *&p -
| p+1 - *&p+1 -
| p++ - *&p store rvalue+1 into p
| (I'm using 'p aka "literal p" as the "lvalue" representation of p. It's
| not really the same thing as just the "address of p", because it's more
| of a "conceptual access to 'p'" - where the "conceptual access" becomes a
| _real_ access either through the act of dereferencing it _or_ through the
| act of assigning it)
| Can anybody buy into this way of thinking?
I'm not sure I agree with you since *p is always an lvalue in C++ each
time p is an expression of pointer type.
Nobody is denying that an rvalue is an entity by itself.