------- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 01:42 -------
Subject: Re: gcc -O2 discards cast to volatile
"gcc2eran at tromer dot org" <[EMAIL PROTECTED]> writes:
| > but that is a fundamental departure from the language semantics.
| > Replace "volatile" with "const" -- both are qualifiers -- and observe
| > the disaster that would ensue.
|
| I must be showing my ignorance again, but what disaster would that be?
If when the compiler sees "const T* p", it assumes that *p is
effectively const, then it would miscompile
int foo(int* p, const int* q) {
int r = *q;
*p = r * r;
return *q;
}
If the compiler assumed that *q is effectively const, therefore cannot
have its value changed through *p, then the following assertion will fail
int i = 4;
assert(foo(&i, &i) == 16);
because the compiler could just return the cached value "r".
There is more a pointer than just its type.
| BTW, according to your interpretation, what is the standard-compliant behavior
| of the following?
|
| void quux(int *bar) {
| *bar = 42;
| }
|
| volatile int foo;
| quux((int*)&foo);
[#5] If an attempt is made to modify an object defined with
a const-qualified type through use of an lvalue with non-
const-qualified type, the behavior is undefined. If an
attempt is made to refer to an object defined with a
volatile-qualified type through use of an lvalue with non-
volatile-qualified type, the behavior is undefined.113)
The footnote says
113This applies to those objects that behave as if they were
defined with qualified types, even if they are never
actually defined as objects in the program (such as an
object at a memory-mapped input/output address).
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
