From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23263 invoked by alias); 2 Jul 2005 22:08:39 -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 23247 invoked by alias); 2 Jul 2005 22:08:36 -0000 Date: Sat, 02 Jul 2005 22:08:00 -0000 Message-ID: <20050702220836.23246.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/msg00214.txt.bz2 List-Id: ------- Additional Comments From gdr at integrable-solutions dot net 2005-07-02 22:08 ------- Subject: Re: gcc -O2 discards cast to volatile "pinskia at gcc dot gnu dot org" writes: | See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html. Both those issues about completely *different* from the issue submitted in this PR. In the above cases, the accessed object actually is NOT volatile. This is not the same here. In this PR, the only thing the function sees is that its parameter is not declared pointer to volatile char, but just pointer to char. That is NO basis for the compiler to assume that the cast performed inside the body is invalid assumption. No. Never. Consequently, it must assume that the pointed-to object might be effectively volatile and consequently generate corresponding code. There is a difference between cv-qualified object and a pointer to cv-qualified object. In the former cases, you do know for sure how the object behaves, in the latter you don't. Consequently you must make conervative assumptions. | What |Removed |Added | ---------------------------------------------------------------------------- | Status|UNCONFIRMED |RESOLVED | Resolution| |DUPLICATE Andrew -- Once again, refrain from closing an issue when you do not fully understand the issue at hand. The PR should be reopen as wrong-code generation. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278