[Bug c/22278] gcc -O2 discards cast to volatile

[hugh at mimosa dot com]

------- Additional Comments From hugh at mimosa dot com  2005-07-16 16:18 -------
Here is some C Lawyering from Henry Spencer.  I asked him to look at and comment
on this bug.  With his permission, I'm quoting his response here.

There is little room for compiler writers to maneuver here, unless they
have announced their intentions in advance in their documentation. 
Reading C99 carefully:

6.5.3.2:  applying `*' to a pointer of type `T *' which points to an
object yields an lvalue of type `T' designating that object.  So the
lvalue in the assignment has a volatile-qualified type. 

6.3.2.1:  when an object is said to have a particular type, the type is
specified by the lvalue used to designate the object.  So the lvalue
having a volatile-qualified type *means* that the object it designates has
a volatile-qualified type; "has type X" and "is designated by an lvalue of
type X" are synonymous (!).

6.7.3:  any expression referring to an object of volatile-qualified
type must be evaluated strictly by the rules of the abstract machine,
although precisely what constitutes an "access" to the object is
implementation-defined.  (Note, "implementation-defined" behavior is
required to be well-defined and *documented*.)  So if the reference in
question is an "access", it must occur where the abstract machine says
it should.

5.1.2.3:  the abstract machine evaluates all expressions as specified by
semantics and all side effects must occur, side effects including
"accessing a volatile object"; implementations are allowed to skip part
of expression evaluation only if they can deduce that no needed side
effects (notably "accessing a volatile object") are therefore skipped. 
So if the reference is an "access", it must occur, period.

I see no useful wiggle room in the difference between "access" and
"accessing", or the difference between "volatile object" and "object of
volatile-qualified type".  These appear to me to be minor accidents of
inconsistent terminology, not useful to a sane implementer.

6.7.3 says that to refer to an object "defined with" volatile-qualified
type "through use of an lvalue" with non-volatile-qualified type yields
undefined behavior.  However, the reference here uses a volatile-qualified
lvalue, so this is not relevant.  A pointer value is not an lvalue; there
is no lvalue present until the `*' operator is applied. 

Surprising though it might seem, I see no express or implied permission to
distinguish based on whether the object in question was *defined* with a
volatile-qualified type.  There are places in the standard where how an
object is defined is significant, e.g. the rules for `const' and the part
of 6.7.3 noted in the previous paragraph, but none of them is part of the
chain of reasoning above.

The only loophole is the definition of "access".  If GCC wishes to claim
standard conformance, GCC is required to document its definition.  I'm not
aware of any mention of this in the GCC documentation, although I haven't
dug hard for it. 

I see no room for a reasonable definition of "access" which retains some
useful meaning for `volatile' and doesn't cover the reference in question. 
(I agree that you can contrive a definition which contains special-case
wording to cover this case, but not that it's reasonable to do so.)

If GCC (a) wants to be C99-conforming, and (b) wants to provide useful
semantics for `volatile', this is a bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278