From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5775 invoked by alias); 16 Jul 2010 15:20:44 -0000 Received: (qmail 5761 invoked by uid 22791); 16 Jul 2010 15:20:43 -0000 X-SWARE-Spam-Status: No, hits=-1.7 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; Fri, 16 Jul 2010 15:20:38 +0000 Received: (qmail 30740 invoked from network); 16 Jul 2010 15:20:36 -0000 Received: from unknown (HELO ?192.168.0.104?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jul 2010 15:20:36 -0000 Message-ID: <4C4078C6.1020104@codesourcery.com> Date: Fri, 16 Jul 2010 15:20:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Nathan Sidwell CC: Mike Stump , 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> <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> <4C2852F4.6070809@codesourcery.com> <4C319EF7.4040001@codesourcery.com> <3721950A-1FF1-441A-A22E-D19507FC36FB@comcast.net> <4C36CE16.2030200@codesourcery.com> <4C4013FB.8090203@codesourcery.com> In-Reply-To: <4C4013FB.8090203@codesourcery.com> 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: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg01366.txt.bz2 Nathan Sidwell wrote: > Is there consensus on what the semantics should be? > > Any suggestions as to how to move forward? In the abstract, I think the EDG semantics make the most sense. I think the VC++ semantics are plausible, but extreme. I think the various in-between states that GCC has adopted over the years are just woefully inconsistent. So, my first preference would be to adopt the EDG semantics, and my second preference would be to adopt the VC++/trunk semantics. My preference for the EDG semantics is somewhat offset to some extent by the fact that our current semantics are "more like" GCC's past behavior, i.e., they are more backward-compatible. One of the reasons I do not like the VC++/trunk semantics are that using assert-like macros will change behavior. For example: #define check(X, Y) (X) ? (Y) : abort() check (condition, vobj = 3); I think it's quite surprising that this generates a *read* from vobj, even though: vobj = 3; does not. I would prefer not to insert reads except where absolutely required because (a) they may change the state of hardware in surprising ways, and (b) they cost cycles. In short, by requiring rereads, we're setting GCC up to underperform competing compilers on embedded systems. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713