From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16609 invoked by alias); 3 Jul 2005 02:30:12 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 16594 invoked by uid 48); 3 Jul 2005 02:30:09 -0000 Date: Sun, 03 Jul 2005 02:30:00 -0000 Message-ID: <20050703023009.16593.qmail@sourceware.org> From: "gcc2eran at tromer dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050702164323.22278.olivier.baudron@m4x.org> References: <20050702164323.22278.olivier.baudron@m4x.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c/22278] gcc -O2 discards cast to volatile X-Bugzilla-Reason: CC X-SW-Source: 2005-07/txt/msg00241.txt.bz2 List-Id: ------- 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