[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted

["gcc2eran at tromer dot org" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]


------- Additional Comments From gcc2eran at tromer dot org  2005-07-03 06:50 -------
> Did you read what was writting in comment #1 and #4?

Carefully. Similarly to Paul Schlie in comment 5, I don't agree. My reasoning
follows.


> Because at this point avail is known not to volatile.  

That is irrelevant. According to the standard, all that matters is whether
*(volatile int *)&avail has a volatile-qualified type, which it does. Please
bear with me as I repeat the argument from PR 22267 comment 23, quoting N1124:

"[6.7.3/6] An object that has volatile-qualified type may be modified in ways
unknown to the implementation or have other unknown side effects. Therefore any
expression referring to such an object shall be evaluated strictly according to
the rules of the abstract machine, as described in 5.1.2.3. [...]"

All other references to the semantics of volatile likewise talk about "objects",
so let's look up their definition:

"[3.15/1] object: region of data storage in the execution environment, the
contents of which can represent values"
"[3.15/2] NOTE When referenced, an object may be interpreted as having a
particular type; see 6.3.2.1."

And here comes the punchline: what is the type of an object?

"[6.3.2.1/1] [...] When an object is said to have a particular type, the type is
specified by the lvalue used to designate the object. [...]"

And also, later on:

"[6.5.3.2/4] The unary * operator denotes indirection. If the operand [...]
points to an object, the result is an lvalue designating the
object. If the operand has type ‘‘pointer to type’’, the result has type
‘‘type’’. [...]"

And just to be sure about whether "volatile" is part of the type thus specified
by the lvalue:

"[6.2.5/26] [...] The qualified or unqualified versions of a type are distinct
types [...]."


Hence, any access to an lvalue whose type is volatile-qualified must be
evaluated strictly according to the rules of the abstract machine. So the
semantics are completely local, caring only about the type of the lvalue. The
type using which the "actual object" being dereferenced was originally defined
is irrelevant.

-- 


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