This is the mail archive of the
mailing list for the GCC project.
Re: Volatile MEMs in statement expressions and functions inlinedastrees
- From: Linus Torvalds <torvalds at transmeta dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>, <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 15 Dec 2001 16:38:02 -0800 (PST)
- Subject: Re: Volatile MEMs in statement expressions and functions inlinedastrees
On Sun, 16 Dec 2001, Jason Merrill wrote:
> C99 Standard, Simple assignment:
> In simple assignment (=), the value of the right operand is
> converted to the type of the assignment expression and replaces the
> value stored in the object designated by the left operand.
> Here, 'the value stored' clearly refers to the value in the object BEFORE
> the assignment.
Hey, finally some valid argument about the _real_ issue.
And, yes, I agree, and I see where you're coming from. You can certainly
parse the passage that way for the assignment operation too. Mea culpa.
> > I further claim that NOWHERE does the standard say that the "lvalue to
> > rvalue conversion" is an "access". Show me. I've quoted the passage, and
> > I've pointed out that nowhere in the definition of "lvalue-rvalue"
> > conversion does it _ever_ say anything about accessing the object
> > associated with the lvalue.
> But what else *could* it mean?
It could easily mean that some expressions have the rvalue in and of
themselves, like an assignment.
> [conv.lval] says that an l-r conversion
> inside sizeof is not an access. Does that not suggest to you that such a
> conversion outside sizeof IS an access?
No, it suggests that it sometimes _can_ be. Which makes perfect sense if
it is something that doesn't happen all the time.
In particular, imagine a completely hypothetical operation that inherently
_knows_ what the "value contained within the object" is..
Yeah, right. The "completely hypothetical operation" isn't all that
hypothetical. It's obviously the operation that _sets_ the value.
It's called an assignment.
See, assignments are special. They ihnerently access the object in
themselves. You don't _need_ any other "access" to know what the value is.
In contrast, in the _absense_ of an assignment, how would you know what
the "value contained"?
Right. For _all_ other operations, you have to read it.
That's what makes assignments special. They are the _only_ operations
where you know that the "value contained" is a priori.
Which means that they are also the only operation where the "lvalue to
rvalue conversion" does not have to involve an access.
See my argument?
> Did you ever look at the issues list URL I pointed you at? Again, the C++
> core language subcommittee discussed this stuff on the email reflector, and
> at the last meeting. What I'm telling you is the consensus. Your position
> was brought up, considered, and set aside. Bring it up on comp.std.c++ if
> you disagree.
I looked at it, but it was marked as (a) still open (ie no conclusion),
and (b) the _basic_ issue there is not "a = b = c", but "(a = b) = c" due
to the need for a sequence point to avoid undefined behaviour for
(a += b) += c
which otherwise has the "a is read and written multiple times without an
explicit sequence point" problem.
To the (for that discussion) side question as to whether "a = b = 0" reads
b multiple times, there was only disagreement.
The _sequence_point_ issue was relevant not for the case of
"lvalue->rvalue" conversion at all, but for the "it stays as an lvalue"
Sequence points have little meaning for repeated loads, only for repeated
stores (and ordering between them).
So I don't think that discussion is an issue here.
Your point on "value stored" is well taken, though, and I agree that you
can read it that way.