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: Linus Torvalds <torvalds at transmeta dot com>
- To: Gabriel Dos Reis <gdr at codesourcery dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 13 Dec 2001 12:33:34 -0800 (PST)
- Subject: Re: Volatile MEMs in statement expressions and functions inlined as trees
On 13 Dec 2001, Gabriel Dos Reis wrote:
> | Whether you _use_ the value of an assignment or
> | not MUST NOT CHANGE THE SEMANTICS OF THE ASSIGNMENT.
> In C++, it does. That comes from the lvalue-to-rvalue transformation.
But why do you insist on the lvalue-to-rvalue conversion having to be a
That flies in the face of the C++ standard itself, which was quoted in
The lvalue-to-rvalue conversion is (for an assignment) defined to be "the
value stored in the left operand after the assignment hass taken place".
There is no "dereference" there.
> That equivalence is based on the (C++) standards text. You're free to
> disagree how things are in C++, but not just because you disagree with
> C++ makes GCC behaviour not conformant.
I do not disagree with C++.
I disagree with your completely made-up rules for lvalue->rvalue
You have made up two rules that are clearly WRONG.
- made-up-rule #1: the conversion only happens when needed.
This "rule" is not supported by any standard I have ever seen, and
it is _not_ supported by existing gcc practice.
- made-up-rule #2: lvalue->rvalue conversion is a dereference
This "rule" is _also_ not supported by any standard I have ever
seen, and is in fact in direct violation of the quoted part of the
It is also _not_ supported by existing gcc practice.
> You have it wrong. Go and check out.
Quote me the standard. I've quoted the standard to you, and have tried to
show that your arguments are logical fallacies.