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 inlinedastrees


>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:

> On 15 Dec 2001, Alexandre Oliva wrote:
>> 
>> > Also, I still claim that the standard CLEARLY SAYS (5.17.1):
>> 
>> >   "..the result of the assignment operation is the VALUE STORED.."

> The meaning of "result of the assignment is the value stored" is not open
> to much debate.

Actually, it is.  A close reading indicates that "the value stored in the
left operand" means "the value WHICH IS CURRENTLY stored in the left
operand", not "the value WHICH WE JUST stored in the left operand".

Evidence:

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.  And, if you want C++ text,

C++ Standard, [basic.lval]:

  If a program attempts to access the stored value of an object through an
  lvalue of other than one of the following types the behavior is undefined:

Again we have the "stored value" of an object that does not refer to the
act of assignment.  And there are other examples.  Even the passage in
question,

  The result of the assignment operation is the value stored in the left
  operand after the assignment has taken place

makes more sense when parsed this way.  Otherwise, it would seem to be
talking about storing a value after assigning a value.

> 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?  [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?  How else do you suppose the notion
of loading a value from memory/register is expressed?  The only reason we
call it "lvalue to rvalue conversion" is because we don't want to talk
about machine-level semantics.

No, nowhere does it actually say that this is an access.  But then, nowhere
does it say that ANYTHING is an access, and presumably something is.  This
seems like an awfully good candidate to me.  The assumption seems to be
that if the standard doesn't explicitly say that something isn't an access
(as with sizeof, above), then it is.

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.

Jason


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