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:

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

I don't see how you can conclude that from [conv.lval].  It says,

  The value contained in the object indicated by the lvalue is the rvalue
  result.

For non-volatile variables, if we already know that value for some reason,
we don't need to look inside the object.  But for volatiles, we can't know
the value, so we need to fetch it again.

> See, assignments are special. They inherently access the object in
> themselves. You don't _need_ any other "access" to know what the value is.

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

Yes, but I don't see anything in the text to suggest that assignment is
special in this way.  I can understand the desire to make it so with some
sort of lvalue-rvalue duality as Alexandre has been suggesting, and as
Erwin suggested toward the end of the issue discussion, but I don't see how
you can read that into the existing text.

And I don't see why 'p = q = 42' is an important enough case to merit
special handling.  For a plain assignment, which is all anyone should be
doing with volatiles, this doesn't matter.

Jason


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