From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22128 invoked by alias); 21 Jun 2010 14:50:05 -0000 Received: (qmail 22115 invoked by uid 22791); 21 Jun 2010 14:50:04 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Jun 2010 14:49:57 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 3DC248672B; Mon, 21 Jun 2010 16:49:55 +0200 (CEST) Date: Mon, 21 Jun 2010 15:46:00 -0000 From: Michael Matz To: Nathan Sidwell Cc: IainS , Richard Guenther , GCC Patches Subject: Re: [gimple] assignments to volatile In-Reply-To: <4C1F75CC.3090608@codesourcery.com> Message-ID: References: <4C1F5380.1090107@codesourcery.com> <4C1F75CC.3090608@codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-06/txt/msg02041.txt.bz2 Hi, On Mon, 21 Jun 2010, Nathan Sidwell wrote: > > implies a read from vobj, also > > return vobj = x; > > implies a read from vobj. > > Also, doesn't that contradict the sequence-point rules? We'd have a > read and write of vobj without an intervening sequence point (and the > read was not used to determine the to-be-written value). I think there's no problem. We have three side-effects for the above expression: two accesses to vobj (one read (1), one write (2)), and the modification of object vobj (3). The separation of the volatile write access and the actual modification of value may seem academic, but let's follow the letter. All these side-effects must be complete before the next sequence point (we have only one here, the end of full expression), which will obviously be the case, no matter if there's side-effect (1) or not. Now, onto 6.5 #2: Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.70) This talks only about the side-effect of changing the stored value (which we do only once) and about the prior value, which we don't use at all. I.e. I think volatility doesn't enter the picture as far as 6.5. #2 is concerned, it rules out the usual pattern of "i=i++ + 1", no matter if i is volatile or not. Ciao, Michael.