From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15238 invoked by alias); 3 Jul 2005 07:27: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 15204 invoked by alias); 3 Jul 2005 07:27:07 -0000 Date: Sun, 03 Jul 2005 07:27:00 -0000 Message-ID: <20050703072707.15202.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/msg00259.txt.bz2 List-Id: ------- Additional Comments From gdr at integrable-solutions dot net 2005-07-03 07:27 ------- Subject: Re: gcc -O2 discards cast to volatile "schlie at comcast dot net" writes: | (In reply to comment #35) | > Subject: Re: gcc -O2 discards cast to volatile | | I apologize for interjecting, but wanted to verify my perception the | conclusions reached; are they essentially?: | | - although an object referenced through a qualified lvalue which differs | from that object's declaration may result in an undefined behavior (as | an implementation may specifically allocate objects based upon their | respective qualification, therefore may result in an unanticipated | behavior if referenced as being dissimilarly qualified). | | - that object should be effectively be treated as specified by that | qualified lvalue unless the compiler knows factually that it's | correspondingly implied side effects will not affect the program's | otherwise specified behavior. | | (where lvalue in this context is any object's reference, | which may refer to either a source, or destination value.) | | Therefore: | | int i; | const int ci: | volatile int vi; | | *(int*)&ci = 0; // should treat ci as int, although may result in | // unexpected behavior as const may be read-only. This is undefined behaviour and on plateforms where GCC put const object in read-only sections, you're in serious troubles. Other compilers may do more "interesting" things, or less. | int* foo(const int * ci){ | return (int*)ci; | } | *(foo(ci)) = 0; // as above. Yes, again undefined behaviour. | *(int)&vi = 0; // should treat as non-volatile, although may | // may result in unexpected behavior if special | // volatile things happen when a volatile allocated | // object is physically addressed for example. undefined behaviour -- assuming you meant *(int*)&vi -- quotes from the standard already provided. | *(volatile int*)&i = 0; // should treat as volatile, although may | // result in unexpected behavior if true | // volatile objects need to be declared as | // such to be specially allocated to satisfy | // an implementation's defined behavior. This is unclear, reported in past and considered bugs is user codes as far as GCC is concerned. gcc2eran thinks this should be accepted. The issue is further confused by the fact that C has a rather interesting formulation of its object model. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278