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:

| In article <fln10n370l.fsf@riz.cmla.ens-cachan.fr> you write:
| >
| >Absolutely not.  Please re-read what Jason said -- the result of the
| >assignment is an *lvalue*.  Thus
| >
| >	p = 0;
| >
| >is equivalent to
| >
| >	(p = 0, &p);
| 
| You and Jason must be on drugs.

Not more than you must be.

[...]

| I stand by my argument.

Not just because you stand by your argument, it will make your claims right.

|  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.

| The fact that a
| C++ compiler thinks that an assignment is also an lvalue does not change
| things one _iota_.  Jasons arguments that it has any relevance are
| illogical, and make no sense, simply because the equivalence that he
| (and you) claim exists obviously does NOT exist. 

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.

[...]

You have it wrong.  Go and check out.

[...]

| And _everybody_ agrees with the fact that "p = 0" should _not_ read the
| value of "p".  Thus "q = p = 0" should _also_ not read the value of "p",

That is true in C, not in C++.  That was already explained.  You're
free to disagree, but not just you disagree means our reading is
incorrect. 

-- Gaby


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