This is the mail archive of the gcc-patches@gcc.gnu.org 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: [gimple] assignments to volatile


On Mon, Jun 21, 2010 at 3:30 PM, Michael Matz <matz@suse.de> wrote:
> Hello,
>
> On Mon, 21 Jun 2010, Richard Guenther wrote:
>
>> > I've come across inconsistent and surprising behaviour when assigning
>> > to volatile lvalues.
>> >
>> > Sometimes we re-read the assigned-to object, and sometimes we do not. ?For
>> > instance,
>> > ? return vobj = data;
>> > will cause a reread of vobj, IF data is not a constant.
>
> 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).
>
>> > or
>> > ?cond ? vobj = data : 0
>> > will cause a reread of vobj, even when we don't use the result of the
>> > conditional expression -- unless data is a constant, in which case there is
>> > no-reread. ?(And confusingly, if you put void casts inside the two
>> > conditional sub-expressions, the re-reading goes away, but it doesn't even
>> > when you explicitly cast the whole expression to void).
>> >
>> > In the attached testcase, test_1, test_6 and test_7 have this surprising
>> > rereading behaviour.
>> >
>> > The fault appears to be in gimplify_modify_expr, where we return the LHS as
>> > the value, if the caller wants the value. ?The attached patch changes that
>> > routine when the target lvalue is volatile. ?In that case it will create a
>> > temporary to hold the RHS value, assign that temporary to the LHS and then
>> > return the temporary.
>
> ... which implies that I think that this is exactly the wrong solution.

And also implies that the frontend should arrange for what
gets used.

Richard.

>
> Ciao,
> Michael.


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