From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23786 invoked by alias); 17 Jul 2005 05:19:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23776 invoked by uid 22791); 17 Jul 2005 05:19:04 -0000 Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 17 Jul 2005 05:19:04 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6H5J2mE077482 for ; Sun, 17 Jul 2005 05:19:02 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6H5J2nG108098 for ; Sun, 17 Jul 2005 07:19:02 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6H5J1eo019610 for ; Sun, 17 Jul 2005 07:19:01 +0200 Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j6H5J1jB019607; Sun, 17 Jul 2005 07:19:01 +0200 In-Reply-To: Subject: Re: volatile semantics To: Gabriel Dos Reis Cc: Dale Johannesen , Daniel Berlin , gcc@gcc.gnu.org, "D. Hugh Redelmeier" , joseph@codesourcery.com, Mike Stump , Nathan Sidwell Message-ID: From: Michael Veksler Date: Sun, 17 Jul 2005 05:19:00 -0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-SW-Source: 2005-07/txt/msg00706.txt.bz2 Gabriel Dos Reis wrote on 17/07/2005 06:07:29: > Daniel Berlin writes: > > | Anything it sees anything in a statement with volatile, it marks the > | statement as volatile, which should stop things from touching it > | (anything that *does* optimize something marked volatile is buggy). > great! > I can't agree with that as is. I would refine it to: Anything that *does* optimizes away visible reads or writes of something marked volatile is buggy. > | I should note that this will probably annoy the people who reported : > | > | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506 > > The rationale is: > > GCC doesn't know what constitutes a reference to a volatile memory, > so it never performs operations on them directly. It will always > pull the value into a register first. This can be optimized, without violating the rule for read/write visibility. It was over a decade since I were on a Pentium validation team, so I may be wrong: inc mem - without a LCK prefix is not atomic, generating a read, and then write - behaving as if it were 3 instructions: [read mem; inc; write mem]. What I am getting at, is that gcc is *allowed* to optimize any sequence of the form [read mem; arithmetic; write mem] to [arithmetic mem], even for a volatile int. I do *not* say that this *has* to be optimized, only that it could. If it had to, gcc would have a very difficult time with RISC load/store architectures. No reasonable interpretation of the standard may claim that gcc *should* generate a single "inc y". I claim that in this case gcc *could* generate a single "inc y", and as such it is a missed optimization (and the PR is valid). It may be a very difficult optimization to implement, so it can be postponed indefinitely, but it should not be marked INVALID. It should be marked a SUSPENDED missed optimization opportunity (for x86 and probably several other CISCs - as long as read/write is not atomic). Michael