From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10937 invoked by alias); 11 Aug 2010 22:55:09 -0000 Received: (qmail 10523 invoked by uid 48); 11 Aug 2010 22:54:55 -0000 Date: Wed, 11 Aug 2010 22:55:00 -0000 Message-ID: <20100811225455.10522.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/45235] const volatile read moved out of order In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "bigotp at acm dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00913.txt.bz2 ------- Comment #4 from bigotp at acm dot org 2010-08-11 22:54 ------- I don't see that the const qualifier should be relevant: doesn't it simply indicate that the code is not permitted to write through that lvalue? (FWIW, the real code uses a memory mapped address and the const qualifier was placed on the address declaration by the chip manufacturer. I assume that a write to the location may be interpreted as a command to the hardware to self-destruct.) Given that, the existing behavior appears to be a clear violation of the requirement that volatile accesses not be re-ordered across sequence points. In concept, I like rguenth's solution (which I haven't tested), as it fits with the documented semantics of MEM_READONLY_P indicating "not modified during the lifetime of the program", something that certainly can't be said of any readable volatile object. That the RTL flag is stored in a field named "unchanging" is a lot more clear than "READONLY". I think that approach eliminates the need to muck with any of those other places where the same problem might be occurring. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45235