For the testcase int x; int foo(void) { x = 0; return *(volatile int *)&x; } the tree-optimizers omit the volatile cast and cprop 0 to the return statement which is invalid. This is a regression from 3.4 where we produced (with -O) foo: pushl %ebp movl %esp, %ebp movl $0, x movl x, %eax popl %ebp ret and now foo: pushl %ebp movl %esp, %ebp movl $0, x movl $0, %eax popl %ebp ret
This is undefined, see the full discussion on the gcc list: http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html
The only construct I can make gcc deal with mixed (non-)volatile qualifiers is a union like in union { volatile int x; int y; } u; int foo(void) { u.y = 0; return u.x; }
(In reply to comment #1) > This is undefined, see the full discussion on the gcc list: > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html - out of curiosity, it's not clear that the discussion reached any conclusion which enables GCC to disreguard the type semantics as specifed by the program code. Where in the standard does it specify that a type qualifier may be disreguarded if convenient? (candidly, I would have exected the specifed rvalue reference to x to force x's logical value into memory if not previously done, and then subsequently re-accessed to satisfy the union of both semantic interpretations.)
(In reply to comment #3) > (In reply to comment #1) > > This is undefined, see the full discussion on the gcc list: > > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html > > - out of curiosity, it's not clear that the discussion reached any > conclusion which enables GCC to disreguard the type semantics > as specifed by the program code. Where in the standard does it > specify that a type qualifier may be disreguarded if convenient? See http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > This is undefined, see the full discussion on the gcc list: > > > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html > > > > - out of curiosity, it's not clear that the discussion reached any > > conclusion which enables GCC to disreguard the type semantics > > as specifed by the program code. Where in the standard does it > > specify that a type qualifier may be disreguarded if convenient? > > See http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html Thanks for the reference, I reviewed it and agree, but not for the reason stated. It has nothing to do with the declared type of the object, as a volatile qualified lvalue reference requires the object be accessed as a volatile, but may be fully optimized away iff it can be "deduced" that its omission would have no effect on the program's behavior. This was only reasonable to "deduce" because the objects address was not itself a literal address, or assigned to a volatile reference either directly or indirectly through a potential alias (as doing so would have extended the visibility of the object beyond the program itself, thereby requiring that the specified volatile access semantics be retained). In other words, in the following program variants, the specified volatile access could not have been optimized away: --- int avail; (volatile int *)0x0123 = &avail; // because it's value is now potentially // modifiable external to the program. int main() { while (*(volatile int *)&avail == 0) continue; return 0; } --- int *avail = (int *)0x0ABC; // as above, it's allocated location isn't private. int main() { while (*(volatile int *)avail == 0) continue; return 0; } --- Thanks, If this is what GCC formally does, it would be nice to see it documented?
*** Bug 22278 has been marked as a duplicate of this bug. ***
Why was this bug closed? The testcases in comment 5 do *not* pass. Here's the first testcase, fixed to compile cleanly: ---------------- int avail; int main() { volatile int **outside = (volatile int**)0x0123; *outside = &avail; // avail is now potentially modifiable externally to the program while (*(volatile int *)&avail == 0) continue; return 0; } ---------------- Following the reasoning of comment 5, the read in the loop must not be optimized away. Still, gcc 4.0.0 with -O3 produces this: ---------------- ... movl $avail, 291 movl avail, %eax testl %eax, %eax je .L5 xorl %eax, %eax leave ret .L5: jmp .L5 ----------------
*outside = &avail; Because at this point avail is known not to volatile. Did you read what was writting in comment #1 and #4?
> 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.
To make it easier to evaluate my claim, here are all messages in the thread linked from comment 1 that seemingly contradicy comment 9: Nathan Sidwell: http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html Dale Johannesen: http://gcc.gnu.org/ml/gcc/2005-05/msg00090.html Andrew Haley: http://gcc.gnu.org/ml/gcc/2005-05/msg00144.html All of these, I am sorry to say, misinterpret the standard since they misconstrue the meaning of the term "object" in the C type system. They assume that the object's type is determined by the way it was created (which is indeed the usual meaning in other languages), whereas the standard quite clearly defines an object's type to be determined by the lvalue referencing it. To give one example of this confusion, here is what Dale Johannesen said: "the standard consistently talks about the type of the object, not the type of the lvalue, when describing volatile." And here is what N1124 [6.3.2.1/1] says: "When an object is said to have a particular type, the type is specified by the lvalue used to designate the object." See my point? I admit to earning my language lawyer diploma on languages other than C, but the evidence in comment 9 seems very firm to me. Does anyone see any flaw in it? If not, then shouldn't this bug be reopened? Hey, we should be *happy* that we found a standard-compliance excluse to fix the code-breaking regression and make those casts work like everybody wanted!
(In reply to comment #10) > Hey, we should be *happy* that we found a standard-compliance excluse to fix the > code-breaking regression and make those casts work like everybody wanted! - I couldn't more strongly agree.
Correction of typo in comment 9: the related PR referenced is PR 22278.
Subject: Re: [4.0/4.1 regression] Casts in folding *& omitted gcc2eran at tromer dot org wrote: > And here is what N1124 [6.3.2.1/1] says: > "When an object is said to have a particular type, the type is > specified by the lvalue used to designate the object." > See my point? In the C99 standard, 6.5.4 Cast Operators, Footnote 85 "A cast does not yield an lvalue. Thus, a cast to a qualified type has the same effect as a cast to the unqualified version of the type."
(In reply to comment #13) > In the C99 standard, 6.5.4 Cast Operators, Footnote 85 "A cast does not > yield an lvalue. Thus, a cast to a qualified type has the same effect > as a cast to the unqualified version of the type." But the object being accessed is the one designated by *dereferencing* the cast expression, and *that* is an lvalue. Quoting N1124: "[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 of course: "[6.5.4/2] Preceding an expression by a parenthesized type name converts the value of the expression to the named type. [...]" I think this answers the first half of your quote (i.e., footnote 86), but I'm not sure what to make of the second half, especially in light of the "Thus".