From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-265923-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5217 invoked by alias); 22 Jun 2010 10:38:18 -0000
Received: (qmail 5205 invoked by uid 22791); 22 Jun 2010 10:38:17 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM
X-Spam-Check-By: sourceware.org
Received: from mail-ww0-f47.google.com (HELO mail-ww0-f47.google.com) (74.125.82.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jun 2010 10:38:11 +0000
Received: by wwb22 with SMTP id 22so201473wwb.20        for <gcc-patches@gcc.gnu.org>; Tue, 22 Jun 2010 03:38:09 -0700 (PDT)
Received: by 10.216.90.2 with SMTP id d2mr4482478wef.24.1277202770671;        Tue, 22 Jun 2010 03:32:50 -0700 (PDT)
Received: from [192.168.2.99] (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62])        by mx.google.com with ESMTPS id d37sm4468038wej.18.2010.06.22.03.32.48        (version=SSLv3 cipher=RC4-MD5);        Tue, 22 Jun 2010 03:32:49 -0700 (PDT)
Message-ID: <4C20961E.4000203@gmail.com>
Date: Tue, 22 Jun 2010 11:36:00 -0000
From: Dave Korn <dave.korn.cygwin@gmail.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Michael Matz <matz@suse.de>
CC: Nathan Sidwell <nathan@codesourcery.com>,  IainS <developer@sandoe-acoustics.co.uk>, Richard Guenther <richard.guenther@gmail.com>,  GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [gimple] assignments to volatile
References: <4C1F5380.1090107@codesourcery.com> <AANLkTimzBtuWYWnzMkmDyM6Y490EIwQJxaDI_higMvJs@mail.gmail.com> <Pine.LNX.4.64.1006211517460.11284@wotan.suse.de> <F8F7EFE5-904D-4066-9F57-1757BB6D18CF@sandoe-acoustics.co.uk> <Pine.LNX.4.64.1006211607500.11284@wotan.suse.de> <4C1F7437.90304@codesourcery.com> <Pine.LNX.4.64.1006211617430.11284@wotan.suse.de>
In-Reply-To: <Pine.LNX.4.64.1006211617430.11284@wotan.suse.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2010-06/txt/msg02146.txt.bz2

On 21/06/2010 15:25, Michael Matz wrote:
> Hi,
> 
> On Mon, 21 Jun 2010, Nathan Sidwell wrote:
> 
>>> Yes, namely that the author explicitely wrote a read access to vobj.
>>> To demonstrate, like
>>>    return vobj;
>>> implies a read from vobj, also
>>>    return vobj = x;
>>> implies a read from vobj.  The latter _also_ implies a store to vobj.  If
>>> you want the read to not happen the author better writes
>>>    vobj = x;
>>>    return x;
>> Then what about plain
>> 	vobj;
>> ?  Is that a read of vobj?
> 
> As said, implementation-defined I think.  (I think we should define it to 
> be no access, unlike 'x = vobj;' even if x is unused later.).

  I'm not so sure, that's how people write code to read-and-discard
auto-resetting flag registers in memory mapped hardware.

    cheers,
      DaveK