From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21715 invoked by alias); 21 Jun 2010 14:06:37 -0000 Received: (qmail 21704 invoked by uid 22791); 21 Jun 2010 14:06:37 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from c2beaomr06.btconnect.com (HELO c2beaomr06.btconnect.com) (213.123.26.184) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 Jun 2010 14:06:32 +0000 Received: from thor.office (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by c2beaomr06.btconnect.com with ESMTP id CZP74478; Mon, 21 Jun 2010 15:05:41 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C1F71B5.0231, actions=tag Cc: Richard Guenther , Nathan Sidwell , GCC Patches Message-Id: From: IainS To: Michael Matz In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: [gimple] assignments to volatile Date: Mon, 21 Jun 2010 14:17:00 -0000 References: <4C1F5380.1090107@codesourcery.com> 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/msg02030.txt.bz2 On 21 Jun 2010, at 14:30, Michael Matz wrote: > On Mon, 21 Jun 2010, Richard Guenther wrote: > >>> I've come across inconsistent and surprising behaviour when >>> assigning >>> to volatile lvalues. >>> >>> Sometimes we re-read the assigned-to object, and sometimes we do >>> not. For >>> instance, >>> return vobj = data; >>> will cause a reread of vobj, IF data is not a constant. > > I'd consider the latter condition a bug. I.e. the rereading must > happen > in every case. It must happen because in C the value of "lhs = rhs" > is > that of reading 'lhs' ("An assignment expression has the value of > the left > operand after the assignment, but is not an lvalue." 6.5.16), and if > lhs > happens to be volatile than the abstract machine implies two > accesses to > lhs, one write (of the assignment) and one read (to get to the value > of > lhs). that answers the "what" but not the "when". Suppose that vobj was a hardware register ... ... I would expect that the assignment would write the value of expr to the register... ... but I would _not_ expect the register to be re-read (and, indeed, in many cases in hardware interaction - that could cause an issue). or did I miss sth? Iain