This is the mail archive of the 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

On 13 Dec 2001, Gabriel Dos Reis wrote:
> |  Whether you _use_ the value of an assignment or
> 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
this thread.

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
	C++ standard.

	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.


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