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

[John McCall]

On Oct 13, 2011, at 5:54 AM, Sebastian Redl wrote:
> On 13.10.2011 14:24, Sebastian Redl wrote:
>> 
>> 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;
>> 
>> Clang is right, GCC is wrong.
> To clarify: this is only C++. In C, the situation is different. C99 6.5.16p3 says:
> "An assignment expression has the value of the left operand after the assignment, but is not an lvalue."
> 
> So in C, GCC is right, and Clang is wrong.

Or rather, in C, Clang would be wrong if it emitted a volatile read here, which it does not.  Clang implements different semantics in the two languages.

> It could be considered a defect of one of the two languages that they differ in such a subtle detail.

Indeed, and the C++ committee has actually made some attempts to change this in C++11, but we haven't implemented those changes yet, and we're likely to only implement them in C++11 mode (i.e., treat C++11 as explicitly changing the semantics, rather than treating it as a true fix).

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111013/8e90f353/attachment.html>