Re: [gimple] assignments to volatile

[Richard Guenther <richard.guenther@gmail.com>]

On Mon, Jun 21, 2010 at 4:07 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Mon, 21 Jun 2010, Nathan Sidwell wrote:
>
>> On 06/21/10 14:30, Michael Matz wrote:
>>
>> > I'd consider the latter condition a bug.  I.e. the rereading must happen
>> > in every case.  It must happen because in C the value of "lhs = rhs" is
>> > that of reading 'lhs' ("An assignment expression has the value of the left
>> > operand after the assignment, but is not an lvalue." 6.5.16), and if lhs
>> > happens to be volatile than the abstract machine implies two accesses to
>> > lhs, one write (of the assignment) and one read (to get to the value of
>> > lhs).
>>
>> The subexpression 'vobj = expr' has a value.  Shouldn't there therefore be a
>> reread of that value in the expression-statement 'vobj = expr;'?
>
> A good question.  I'm very certain that we need a reread for
>  "x = (vobj = y);" .
> (I even thought we had testcases for this actually happening)
> I would find the consequence of also having to reread for "vobj = y;"
> surprising.
>
> There's some leeway in the standard as to what actually constitutes an
> access to a volatile object (implementation-defined), and perhaps we can
> define it to be no (read) access in the second case: The subexpression has
> a value, but the source code doesn't retrieve it, and I think we're free
> to define this non-retrieval to imply no access to the value (and hence to
> vobj).

The standard also specifies that the value has unqualified type
(whether that matters here or not I am not sure).  So x is assigned
from a non-volatile typed value.

Richard.