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 14:55:08 -0800 (PST)
- Subject: Re: Volatile MEMs in statement expressions and functions inlined as trees
On 13 Dec 2001, Gabriel Dos Reis wrote:
> 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.
Now you're changing the rules of C++ parsing, too.
These are _clear_ and not something where you can make up your own rules.
THERE IS NO "q = p" assignment.
The assignment is
q = p = 0;
which parses as
q = (p = 0);
which has _nothing_ to do with your "q = p" variant. You might as well
claim that "q = p + 1" parses as "q = p" - sure, if you ignore basic rules
of the language parsing, you can give the expression any semantics you
want at all.
So it clearly and unambiguously says that "q gets the result of the
_assignment_". There is absolutely no leeway here, and there is NO way you
can claim that it has _anything_ to do with "q = p", without looking like
a complete fool.
This is why the whole thing completely and utterly hinges not on the value
of "p" itself (which is _irrelevant_), but on the value of the actual
_assignment_, and why I think the sentence that talks about the "result of
the assignment" is so critical and crucial to the whole discussion.
That sentence which you have avoided so actively, trying to come up with
arguments (like "q = p") which have nothing to do with the whole issue.
So how _do_ you parse that sentence?
What _do_ you think the "result of the assignment" actually means?