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


Linus Torvalds <torvalds@transmeta.com> writes:

| On 13 Dec 2001, Gabriel Dos Reis wrote:
| >
| > |  - made-up-rule #2: lvalue->rvalue conversion is a dereference
| > |
| > | 	This "rule" is _also_ not supported by any standard I have ever
| >
| > 4.1/2
| >   The value contained in the object indicated by the lvalue is the
| >   rvalue result. When an lvalue-to-rvalue con-version occurs within
| >   the operand of sizeof (5.3.3) the value contained in the referenced
| >   object is not accessed, since that operator does not evaluate its
| >   operand.
| 
| And the above supports your position exactly _how_?

You said that I made up a rule -- which I didn't.  Then you claimed
that the behaviour of lvalue-to-rvalue conversion as a "dereference"
was not even supported by the standard.  Which is clearly false, as
evidenced by the above quote.

| I would say that it only strengthens my case.

It doesn't.

| "The value contained in the object indicated by the lvalue"
| 
| Remeber, the lvalue in question is an _assignment_.

No.  It is the result of the assigment "p = 0".  Now condiser the
second assigmemt "q = p".  To perform that assignment, an
lvalue-to-rvalue conversion is necessariy.

| The special case that affects "sizeof"

I quote the complete bullet for completeness.  Not that I think the
special case of sizeof is necessary here.

[...]

| In short, the passage you quote in no way argues for your interpretation,

It does.  But you, manifestly, do not want to accept facts.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com


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