From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4959 invoked by alias); 5 Jul 2010 09:02:31 -0000 Received: (qmail 4897 invoked by uid 22791); 5 Jul 2010 09:02:30 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Jul 2010 09:02:25 +0000 Received: (qmail 16405 invoked from network); 5 Jul 2010 09:02:24 -0000 Received: from unknown (HELO ?192.168.44.101?) (nathan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jul 2010 09:02:24 -0000 Message-ID: <4C319FAD.1000903@codesourcery.com> Date: Mon, 05 Jul 2010 09:02:00 -0000 From: Nathan Sidwell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Mike Stump CC: Mark Mitchell , Michael Matz , Richard Guenther , GCC Patches Subject: Re: [gimple] assignments to volatile References: <4C1F5380.1090107@codesourcery.com> <4C20D40B.30904@codesourcery.com> <4C20D891.5030506@codesourcery.com> <4C21E361.1040900@codesourcery.com> <4C220762.2060703@codesourcery.com> <025B27D1-E620-4BA2-A113-FD28747E2762@comcast.net> <4C231176.6050501@codesourcery.com> <798730F0-AFFA-4812-AA49-E41A23A02D21@comcast.net> <4C244E2C.9020900@codesourcery.com> <7F30721E-1B2E-41B7-B7BF-F66C936690D9@comcast.net> <4C2840FB.3010409@codesourcery.com> <7069549D-C414-4357-AA66-093F4B73F7E1@comcast.net> In-Reply-To: <7069549D-C414-4357-AA66-093F4B73F7E1@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-07/txt/msg00354.txt.bz2 On 07/01/10 02:02, Mike Stump wrote: > On Jun 27, 2010, at 11:28 PM, Nathan Sidwell wrote: >> On 06/25/10 17:41, Mike Stump wrote: >>> On Jun 24, 2010, at 11:35 PM, Nathan Sidwell wrote: >>>> On 06/24/10 16:42, Mike Stump wrote: >>>> >>>>> Sorry for not expounding. I thought it would be obvious I was talking about well formed code... First case would be something like: >>>>> >>>>> volatile int i, j, k; >>>>> volatile int vi; >>>>> void foo(volatile int& j) { >>>>> foo(i = k); >>>>> } >>>>> >>>>> here, we need to bind j to the address of i. The second case is something like: >>>> >>>> Correct. The patch does not change this behaviour -- the C++ front end already has to explicitly break out the lvalue from the assignment to conform to the semantics of TREEs. The current G++ behaviour is not to re-read the assigned-to value. >>> >>> g++ seems not to share your position: >>> >>> movl _i, %eax >>> movl %eax, (%esp) >>> >>> volatile int i, j, k; >>> volatile int vi; >>> void foo(int j) { >>> foo(i = k); >>> } >>> >>> GNU C++ (GCC) version 4.6.0 20100620 (experimental) [trunk revision 161045] (x86_64-apple-darwin10) >>> compiled by GNU C version 4.2.1 (Apple Inc. build 5659), GMP version 5.0.1 >>> >>> ? Certainly I must misunderstand something, can you spot it? >> >> You have changed the testcase to be passing by value from passing by reference. Why do you think those would be equivalent? > > The read happens when the the object referred to by the reference is accessed: You're now changing the example again. This time with a reference to volatile object. > > volatile int i, j; > int x, data, expr, k; > > static inline void foo(volatile int&r) { > int fetch = r; > } > > int main() { > foo(i=k); > } > > movl _k, %eax > movl %eax, _i > movl _i, %eax > > here, i is re-read. Here, g++ in fact does re-read the assigned to value. Yes I would expect this -- there is a sequence point between the assignment to i in the argument list, and the read of r in the inlined function. I do not understand the point you are trying to make. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery