volatile semantics

[Dale Johannesen]

On May 3, 2005, at 11:52 AM, Nathan Sidwell wrote:

> Dale Johannesen wrote:
>> On May 3, 2005, at 11:03 AM, Nathan Sidwell wrote:
>
>>> Seeing through the const-stripping cast is a useful optimization.
>> It is?  Why would somebody write that?
>
> perhaps a function, which returned a non-const reference that
> happened to be bound to a constant, has been inlined.

OK, I agree.

>> IMO, no, but surely we don't have to worry about this one.  Either way
>> is standard conformant and the user's intent is far from clear, so 
>> whatever
>> we do should be OK.
>
> If we guarantee one to work and not the other, we need to have a clear
> specification of how they differ.  What if intermediate variables -- 
> either
> explicit in the program, or implicitly during the optimization -- get
> introduced?
>
> My guess is that the wording of the standard might be the best that
> could be achieved in this regard.  It would be nice to have some clear
> wording indicating that Mike's example will work, but some other, 
> possibly
> closely related, example will not.

It's not that bad; the type of an lvalue is already well defined (it is 
"int" in
your last example, and "volatile int" in Mike's).  We just take this 
type into
account in determining whether a reference is to be treated as volatile.
(Which means we need to keep track of, or at least be able to find, both
the type of the lvalue and the type of the underlying object.  As you 
say,
gcc may have some implementation issues with this.)

And we don't have to document the behavior at all; it is not documented 
now.