Re: [gimple] assignments to volatile

[Nathan Sidwell <nathan@codesourcery.com>]

On 06/25/10 19:14, Mike Stump wrote:

> I don't find any limitation in 5.17 to scalars or to objects of class type.  If you examine the wording in 8.5.3 for example, a place that we all know does create temporaries:

I did not make the claim that the standard distinguished.  I am make the claim 
that we want simple, consistent and composable rules for accessing scalar device 
registers.

As you brought it up, I stated what I thought of volatile structure semantics.

> In a = vob = c; stucts are treated the same.  This is the case we were discussing.  We can know that, because it appears on the 6th lines of this email.

The case of structs is what you have brought to the mix.  The original 
discussion was about scalars.

>>   I think the behaviour of volatile structs in C++ is too ill-specified to meaningfully talk about when accesses to the members occur.
>
> Again, I disagree.  We could embark upon what the standard says, but, let's just agree to not, unless someone wants to learn what it says, or someone wants to change the status quo behavior in a way that deviates from the standard.

If you do not want to discuss what the standard says, why did you bring it up? 
This whole discussion is about discrepancies within the standards and between 
them and desired semantics.

>> I think the goal should be to make accesses to volatile scalars, as used when poking at hardware, follow simple, composable, consistent rules.
>
> Yeah, the problem with that is implicit in that, is, I want to make the compiler agree to the ruleset I just invented because I like it, and if we do that, the semantics then change day by day, by the whim of the person doing the patch today, and the each implementor gets to choose a different rule, and the users don't benefit.  The other possibility is to make it conform to the language standard, when reasonable.  I think the later is the best option.  No one has argued that they understand what the standard says and want to intentionally deviate from it, nor have they stated a good reason for doing that.

Could you rephrase that please, I cannot understand what you are claiming.

> So, could you please restate what you want to do.  Do you want gcc to follow the language standard, or, would you rather ignore the standard and just invent some rules on the fly for gcc to follow?

I claim the C and C++ standards are both not clear and at odds semantics that 
are necessary for hardware programming.

>>   IMHO the current implemented behaviour is none of those.
>
> Concerning:
>
> 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.
>
> the proper solution is to make it always reread vobj.  Simple and consistent, while matching the standard, no?

did you not read my original problem statement?  You seem to be ignoring 
associated issues that come with that interpretation, which I mentioned.  Could 
you clarify what you also claim the following expression-statements should reread?

vobj;
vobj = data;
expr, vobj = data;

They all have values.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery