From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3387 invoked by alias); 23 Jun 2010 18:37:13 -0000 Received: (qmail 3376 invoked by uid 22791); 23 Jun 2010 18:37:11 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from qmta14.westchester.pa.mail.comcast.net (HELO qmta14.westchester.pa.mail.comcast.net) (76.96.59.212) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Jun 2010 18:37:04 +0000 Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id ZNqw1e0040xGWP85EWd3r7; Wed, 23 Jun 2010 18:37:03 +0000 Received: from c-98-210-246-208.hsd1.ca.comcast.net ([98.210.246.208]) by omta12.westchester.pa.mail.comcast.net with comcast id ZWd01e00C4WWjWi3YWd1iS; Wed, 23 Jun 2010 18:37:02 +0000 Subject: Re: [gimple] assignments to volatile Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mike Stump In-Reply-To: <4C220762.2060703@codesourcery.com> Date: Wed, 23 Jun 2010 19:16:00 -0000 Cc: Nathan Sidwell , Michael Matz , Richard Guenther , GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: <025B27D1-E620-4BA2-A113-FD28747E2762@comcast.net> References: <4C1F5380.1090107@codesourcery.com> <4C20D40B.30904@codesourcery.com> <4C20D891.5030506@codesourcery.com> <4C21E361.1040900@codesourcery.com> <4C220762.2060703@codesourcery.com> To: Mark Mitchell 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/msg02364.txt.bz2 On Jun 23, 2010, at 6:08 AM, Mark Mitchell wrote: > Nathan Sidwell wrote: >=20 >> RVCT generated code consistent with my proposal. Specifically in: >> some_use_of =3D volatile_object =3D value; >> the volatile object is only written to and not read, regardless of the >> context of that volatile assignment (be it return expression, >> conditional expression or serial assignment). >=20 > Good. >=20 >>> vobj; >>> (void) vobj; >>=20 >> Both of these cause a read of vobj in RVCT (and GCC). >=20 > Good. >=20 > If there are no objections within the next 48 hours, I object. gcc semantics are carefully designed. gcc is the standard compiler for muc= h embedded work, C and C++ differ due to the standards organizations, some = of those differences are truly unfortunate, but there you go. If someone w= anted to fix gcc, the proper way would be to get the C and C++ committees o= n the same page, nail it down, or make it a hard error, and remove any lati= tude and confusion and make them agree. C++ says: All require a modifiable lvalue as their left operand and return an lvalu= e referring to the left operand. You can't just willy nilly change this: int i, j, k; void foo(int &j) { foo(i =3D k); } can sense if you get it right or not. Add a volatile on i, and you discove= r, you can't just change this as you see fit, in particular, not in the way= you all seem to want, which is just plain wrong. Further, C says: An assignment expression has the value of the left operand after the assi= gnment Now, this is pretty plain, the value is the left operand. They choose this= wording as they didn't want the return value to be a modifiable lvalue. I= concede there is enough wiggle room here to confuse users and give impleme= ntors enough latitude to try and claim they are following the standard, but= really, the return value is the valuer of the left operand, if it weren't,= the standard would not say it was. It could have said, the value is the v= alue that was stored in the left operand, or the value is the right operand= after conversion to the type of the left operand, or a host of other possi= bilities. > then I think we should consider the semantics settled. I'm not trying to= squash > discussion; if people don't like those semantics, let's discuss. But, I > think existing practice should weigh heavily. This semantic in gcc has been the industry standard for at least 15 years. = If there have been any code written that depend upon this, you break them = all. This breakage is silent, and in the type of code that you really don'= t want to break in this way. I object to the change.