volatile semantics

[Mark Mitchell]

Daniel Berlin wrote:
> On Sun, 2005-07-17 at 05:13 +0200, Gabriel Dos Reis wrote:
> 
>>Daniel Berlin <dberlin@dberlin.org> writes:
>>
>>[...]
>>
>>| > I think that is urgent. 
>>| No offense, but everyone thinks the problems that affect them are the
>>| most urgent.
>>
>>miscompilation of KDE was declared urgent; I hope bug affecting code
>>semantics for X is not just "request for enhancement".
> 
> 
> Not for me to judge. That's why we have Mark.

For the record, I agree with what looks to have been the outcome of this 
thread: that it makes sense to consider an object volatile iff the type 
used to aspect the object is in fact volatile, regardless of its 
underlying type.  Certainly, the standard never requires that we remove 
accesses, and I do think that this rule is what programmers who use 
volatile expect, and it's an easy rule to explain, so, from a QoI point 
of view I think this is a good rule, independently of what behavior 
might be required by the standard.

Note that I'm explicitly not taking a position on what the standard 
says.  The standard is notoriously incomplete with respect to object 
model issues, including volatility, so I think that trying particularly 
hard to parse its words in this area is probably not a good use of time 
for people trying to build a real-world compiler.  Creating DRs is more 
useful than trying to read the tea leaves.

Clearly, the analogous rule does not make sense for "const" in that a 
"const" object can never be modified; in particular, if the compiler can 
prove that "*x = 3" is an attempt to modify an object whose dynamic type 
is "const int", then it can replace that with a call to "kill 
(SIGSEGV)", if it likes; this is unquestionably undefined behavior.

As for putting RTH's change in 4.0.2, I'm comfortable with that, 
provided the usual testing is done, as I think this is at least a QoI 
regression.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304