From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9608 invoked by alias); 29 Jul 2004 11:27:03 -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 9598 invoked by uid 48); 29 Jul 2004 11:27:02 -0000 Date: Thu, 29 Jul 2004 11:27:00 -0000 Message-ID: <20040729112702.9597.qmail@sourceware.org> From: "macro at linux-mips dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040726181156.16721.macro@linux-mips.org> References: <20040726181156.16721.macro@linux-mips.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/16721] [3.5 Regression] Accesses to volatile objects optimized away X-Bugzilla-Reason: CC X-SW-Source: 2004-07/txt/msg03467.txt.bz2 List-Id: ------- Additional Comments From macro at linux-mips dot org 2004-07-29 11:26 ------- (In reply to comment #8) Well, I've missed the section about standard conformance -- thanks for pointing that out. Anyway, the note about C in the C++ section hints about the expected behavior of GCC for read accesses to volatile objects and I am pretty sure it's actually what's widely expected by developers as well. The use of the "volatile" keyword is presently two-fold, specifically: 1. Marking objects referring to hardware that does not behave as plain memory. 2. Marking objects in ordinary memory that can change unexpectedly, e.g. by another CPU or by an interrupt handler. For the latter eliminating dead reads is safe. For the former it is not. Thus one could argue it would be beneficial to differentiate between the two cases, e.g. by defining an additional variable attribute to enable or inhibit such elimination. I don't think it is really necessary -- the performance penalty from a dead read from a memory variable is not that high and volatile objects are special and require special attention from programmers anyway. If there is a possibility of a dead read to happen, then most likely it can be handled explicitly with a conditional statement. And older GCC versions used not to optimize these reads away, so programmers should be prepared for the penalty already. Therefore I propose to keep the old behavior and document it in the standard conformance section to avoid confusion in the future. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16721