From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9593 invoked by alias); 3 Jul 2005 01:42:11 -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 9574 invoked by alias); 3 Jul 2005 01:42:07 -0000 Date: Sun, 03 Jul 2005 01:42:00 -0000 Message-ID: <20050703014207.9573.qmail@sourceware.org> From: "gdr at integrable-solutions dot net" 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/msg00235.txt.bz2 List-Id: ------- 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" 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