[gimple] assignments to volatile
Paul Koning
Paul_Koning@Dell.com
Tue Jun 22 15:56:00 GMT 2010
> Michael Matz wrote:
>
> >>> 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.
>
> I think that it's without question that:
>
> vobj = data;
>
> should not cause a read from vobj; the value is not used. I think
> real-world embedded programmers would be surprised to see a read from
> an
> I/O register there. Do you agree?
Yes. Whatever else you do, this property is mandatory.
> Similarly, I think that:
>
> cond ? vobj = data : ...
>
> should not cause a read from vobj. The conditional in this case is
> just
> a form of if/then; it would surprise programmers if this behaved
> differently from:
>
> if (cond)
> vobj = data;
>
> Do you agree?
Maybe. Personally I would view the statement you listed as bad code.
> The case of:
>
> x = vobj = data;
>
> is different because the value is being used. In that case, I have no
> strong opinion.
>
> Rather than argue about this last case in theory, though, I'd be
> inclined to look at existing practice. What do RealView, CodeWarrior,
> Green Hills or other long-standing compilers for embedded systems do?
> If there's a clear consensus, we can follow that.
Right.
The question on the statement you quoted is whether people interpret it as "data is assigned to two variables" or "data is assigned to vobj and the vobj is assigned to x". I take it from earlier discussion that the standard says the latter. Actually, given that this code is confusing, it might deserve a warning.
Finally, whatever is done must produce the same answer whether the code is compiled as C or C++.
paul
More information about the Gcc-patches
mailing list