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

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

------- Additional Comments From gcc2eran at tromer dot org  2005-07-03 02:30 -------
(In reply to comment #25)
> 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". 

We need to distinguish between the semantics that that must be followed, and
optimizations that preserve these semantics. The way I understand it,
semantics-wise "const" is not a promise, it's only a requirement: it tells the
compiler that it can't change the object directly, that's all. Meanwhile, the
optimizer tries to do various optimizations that preserve the semantics, for
example by noting that variables don't change their values; but in your example
it can't make that assumption without aliasing analysis (which will fail), since
by itself the const-qualified argument guarantees nothing.

So the standard says the semantics are dumb: they considers just the type of the
dereferenced pointer and acts accordingly (forbid direct changes of consts,
apply strict abstrat machine for volatiles). But subject to those semantics, the
optimizer can be as smart as it wants. There's no contradiction here.


>        [#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)

OK. Then the volatile-stripping direction can be handled arbitrarily.


(In reply to comment #26)
> It was my object "bar".

OK. I was looking at comment 17.

-- 


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