From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28824 invoked by alias); 26 Jun 2010 17:30:12 -0000 Received: (qmail 28816 invoked by uid 22791); 26 Jun 2010 17:30:11 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Jun 2010 17:30:06 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 2DDD78D893; Sat, 26 Jun 2010 19:30:04 +0200 (CEST) Date: Sat, 26 Jun 2010 19:52:00 -0000 From: Michael Matz To: Richard Guenther Cc: Mark Mitchell , Mike Stump , Nathan Sidwell , GCC Patches Subject: Re: [gimple] assignments to volatile In-Reply-To: Message-ID: 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> <4C22F307.6010403@codesourcery.com> <4936DDA8-4C55-4CF8-8CA7-D8B4435863BF@comcast.net> <4C236C7A.40303@codesourcery.com> <97293849-2D1F-4DE5-9B35-199E26005768@comcast.net> <4C2451CA.2020906@codesourcery.com> <4C24F908.90409@codesourcery.com> <94650BF2-D60F-4508-8A26-FCD575761052@comcast.net> <4C25780B.9030307@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/msg02686.txt.bz2 Hi, On Sat, 26 Jun 2010, Richard Guenther wrote: > > Backwards compatibility is also the best reason not to change GCC; > > even if the standard unambiguously mandated that we change, it might > > not make sense to change, since it might break code that's worked with > > GCC for a long time. > > What did GCC do for all these cases pre-tree-ssa? Trying 3.3, and this testcase: ----------------------- volatile int vobj1, vobj2, vobj3, vobj4, vobj5, vobj6, vobj7, vobj8, vobj9; int x, y, z; void f1 (int i) { vobj1 = y; x = vobj2 = y; x ? vobj3 = y : z; x = y ? vobj4 = z : i; vobj5; vobj6 = 42; x = vobj7 = 43; x ? vobj8 = 44 : z; x = y ? vobj9 = 45 : i; } ----------------------- I.e. testing all cases we were discussing in this thread, constant and non-constant RHS. cc1 and cc1plus generate the same accesses, in addition optimization levels make no difference (as expected). The relevant instructions are this in all cases: % grep 'mov.*vobj' volatile-check.s movl %edx, vobj1 movl %edx, vobj2 movl vobj2, %eax movl %edx, vobj3 movl %eax, vobj4 movl vobj4, %eax movl vobj5, %eax movl %eax, vobj6 movl %eax, vobj7 movl vobj7, %eax movl %ecx, vobj8 movl %eax, vobj9 I.e. a (re-)read occurs for vobj2, vobj4, vobj5 and vobj7, that is these cases: x = vobj2 = y; x = y ? vobj4 = z : i; vobj5; x = vobj7 = 43; Interestingly a re-read doesn't occur for vobj9: x = y ? vobj9 = 45 : i; that is the same case as vobj4, just with a constant RHS. I'd consider this a bug. (For completeness, the reread of vobj4 of course only happens conditionally) FWIW, our current trunk in addition generates re-reads for vobj3, vobj8 and vobj9. If one were to follow my (and Mikes?) reading of the standard rereading vobj3 and vobj8 would be wrong. All of these compilers agree that a read is to be emitted for a bare vobj access in void context: "vobj5;" but not for the simple assignment "vobj1 = x;". ICC 11.0 and 11.1 only generate a read of vobj5 (i.e. no re-reading occurs at all) for the C language, and no read at all for the C++ language. Ciao, Michael.