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 Dec 14, 2001, Linus Torvalds <> wrote:

> On 14 Dec 2001, Alexandre Oliva wrote:

>> ``The behavior of an expression of the form E1 op= E2 is equivalent
>> to E1=E1 op E2 except that E1 is evaluated only once.'' [expr.ass]/7

> The way I parse it, E1 is "(a += b)" and E2 is "c", with "op" being "+".

> Right?


> So the correct expansion of "E1 op= E2" to "E1 = E1 op E2" is in fact

> 	(a += b) = (a += b) + c;

> together with the "evaluate only once" clause. Agreed?

Yup, that's why I replaced the left-hand `a += b' with `a', since
that's just the lvalue that is going to be modified.

> That is _not_ really equivalent to your expansion.

Certainly not.  But yours evaluates `a+=b' twice, which is explicitly
forbidden.  The right way to do it would be:

  __typeof__(a) &a_ = (a += b); // reference bound to a's lvalue

  a_ = a_ + c;

Now, do you load from a_, even though you know its last-stored rvalue
is `former-a + b'?

What if it was written:

  a_ += c;


> But to be quite honest, I have no idea _what_ it is equivalent to, as that
> expression just makes me go "Huh!?" ;)


> My argument hinges on the fact that I think evaluating "(a += b)"
> returns two different things, both an rvalue _and_ an lvalue, and
> which of them is "E1"?

I agree this model would be nice, but I begin to find problems with
it, at least in C++.  It would require lvalues to carry optional
associated rvalues, such that, whenever you needed the rvalue of that
lvalue, you would use the associated value if there was one, and load
it from the lvalue otherwise, and such that sequence points invalidate
such rvalues, should they be modified by means of other (or even the
same) lvalue.

This would break down should the lvalue be bound to a reference
variable, and the rvalue of the reference be loaded.  Or perhaps
should the reference carry the associated rvalue with it?

Note that this notion of having the rvalue of an lvalue possibly being
different from the value you'd obtain by loading from the lvalue would
lead you to a very complicated model, possibly full of
inconsistencies.  A maze of twisty passages all unlike C++ :-)

Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                  aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist    *Please* write to mailing lists, not to me

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