Re: Volatile MEMs in statement expressions and functions inlined astrees

[Alexandre Oliva <aoliva at redhat dot com>]

On Dec 15, 2001, Linus Torvalds <torvalds@transmeta.com> wrote:

> 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.."
>> 
>> > (emphasis mine).
>> 
>> but that, after the assignment is performed, and the result is
>> actually an lvalue, so it can be asserted that the value stored was
>> written into lvalue, and it can be only assumed that reading it back
>> would get the same value back,

> That's not true, and you know it.

Hmm...  Perhaps I didn't express myself well.  I meant that one can be
sure that the value stored was written, but that there may be doubt on
whether reading the value back would give the same value back.

> 	assert ((*p = 10) == 10);

> and I claim that

>  (a) according to the C++ standard, that assert must NEVER fire

I disagree this can be drawn from the C++ standard.

>  (b) with the current gcc (and your proposal) it _will_ fire on most PC's

Yup.

>> but it's not guaranteed that converting
>> the lvalue resulting from the assignment, whose stored value was the
>> result of the rvalue of the assignment, is to be used should the
>> rvalue of the lvalue be accessed.  It's quite reasonable to do so, but
>> I don't fully agree it's mandated by the Standard.

> The _what_ do you claim that "value stored" thing actually means?

I propose that the meaning of ``The result of the assignment operation
is the value stored in the left operand after the assignment has taken
place; the result is an lvalue.'' may be that the lvalue is guaranteed
to have already been assigned the rvalue, so if you read it back, odds
are that you'll find it there, but the result is still an lvalue,
whose value is probably the stored value.

However, I see why we may want some guarantee that we'll not read the
value back, ever, regardless of the volatility of the lvalue that
results from the first assignment in a chain of assignments.  Think,
for example, of a multi-threaded application: from p = q = 0, you
might expect p to always be set to 0.  But what if the compiler
decided to load the value from q instead of using the stored value,
and another thread wrote a different value in q just between the store
and the reload?

>From this point of view, I like very much the idea of an lvalue that
holds the address and an optional known-value.  However, I find it
quite difficult to generalize this model to more complicated
scenarios, and to think of how to adapt GCC's internal mechanisms so
as to implement this policy.

>> That depends on whether the function returns a reference (lvalue) or
>> not (rvalue).

> It does NOT.

Sure it does.  It depends on the return type of the function, that you
didn't include in your posting.

> The fact that it is an lvalue means that you can do other things with it,
> like take its address.

Or return it by reference, but then the caller will have to access the
variable to convert it to rvalue.  Or could the access be optimized
away should the function call be inlined?

> The fact that it is an lvalue does NOT mean that you can ignore the rest
> of the sentence, and override it.

I'm not ignoring it, I'm just doubtful between two readings that sound
both possibly-correct to me, and that both have supporters that I know
to be capable and knowledgeable, and that I respect very much.  So
it's been hard for me to make up my mind :-)

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

Right.  But the fact that it's an lvalue may mean that the value may
be there, in the variable, should you access it.  I.e., from the
assignment, you get back the value stored, but as an lvalue, i.e., as
a variable that, should it be accessed, would give you back the stored
value, as long as nothing else modified it.  Remember that the C++
Standard doesn't take threads into account, so, except for volatile
memory that is modified outside the scope of the virtual machine on
which a C++ program is modeled to run, you *would* get the stored
value back.

But, just like some people are choosing to neglect the part of the
sentence that says that the result is the stored value, others are
choosing to neglect the fact that it's an lvalue, or trying to impose
an associated rvalue to the lvalue that can't be obtained by accessing
it.  See?  None of the readings is perfectly consistent.

> I further claim that NOWHERE does the standard say that the "lvalue to
> rvalue conversion" is an "access". Show me.

I've suggested that the only hint we could find for this fact is the
absence of access when evaluating the operand of sizeof.  From it, one
could draw the conclusion that, in other cases, the lvalue-to-rvalue
conversion does perform an access, but it would not be on strong
grounds, I agree.

> Yet your WHOLE POINT hinges on that supposed access. The _only_ argument
> you have against the fact that the standard says that the value returned
> is the same as the value stored is the fact that there is a "lvalue to
> rvalue" conversion.

Then let's turn the table around: now you show me where the Standard
says that an lvalue may have an rvalue associated with it that is not
the rvalue you'd obtain by accessing it.  That's your claim: that the
result of an assignment, despite being an lvalue, has an rvalue that
is the stored value, and this rvalue should be used in case of
lvalue-to-rvalue conversion, instead of evaluating the lvalue by means
of accessing it.

> Face it, it does not say "most often". It says that the result _IS_.

It also says the result is an lvalue.  And it doesn't say that lvalues
have rvalues magically attached to them, except for the very rvalues
contained in the variables the lvalues correspond to, and that can be
obtained by accessing them.

> But if you want to debate the meaning of the word "is", then you're in
> great company, and I hope your intern looks better than the intern of the
> last person who tried it.

:-D

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me