[cfe-dev] C++ and volatile lvalue-to-rvalue

[Abramo Bagnara]

Il 13/10/2011 14:24, Sebastian Redl ha scritto:
> On 13.10.2011 13:43, Abramo Bagnara wrote:
>> I want to put this gcc bug report to clang developer attention.
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50364
>>
>> The gcc developers believe that according to the standard
>>
>> volatile int v;
>> x = v = 3;
>>
>> does not imply necessarily a read from v.
>>
>> clang instead add a lvalue-to-rvalue implicit cast outside v = 3
>> assignment (and there is general consensus that lvalue-to-rvalue *is*
>> the marker for memory read access).
>>
> C++11 5.17 [expr.ass]p1 says:
> "The assignment operator (=) and the compound assignment operators all
> group right-to-left. All require a modifiable lvalue as their left
> operand and *return an lvalue referring to the left operand*."
> So the result of (v = 3) is an lvalue referring to v, just as the
> expression (v) alone. Therefore the code is equivalent to the two
> separate statements:
> v = 3;
> x = v;

I definitely don't think that gcc developers would deny that v = 3 value
is an lvalue referring to v.

I'm inclined to believe that they think that there is a sort of "double
path" on exit from "v = 3": on the first path (lvalue) the result is an
lvalue referring v, on the second path (rvalue) the result is that of rhs.

This would be the reason why they write in texinfo doc the following
(emphasis is mine):

"Assignments are *also* expressions and have an rvalue.  However when
assigning to a scalar volatile, the volatile object is not reread,
regardless of whether the assignment expression's rvalue is used or
not.  If the assignment's rvalue is used, the value is that assigned
to the volatile object."

This would make a difference only with volatile and would give some
uniformity with C, but I really don't see how this perspective might be
matched with overloaded assign operators semantic... I'd guess that they
interpret that as an exception.