From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10086 invoked by alias); 24 Jun 2010 16:11:34 -0000 Received: (qmail 10066 invoked by uid 22791); 24 Jun 2010 16:11:32 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from aussmtpmrkpc120.us.dell.com (HELO aussmtpmrkpc120.us.dell.com) (143.166.82.159) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Jun 2010 16:11:27 +0000 X-Loopcount0: from 12.110.134.31 Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 24 Jun 2010 11:11:25 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [gimple] assignments to volatile Date: Thu, 24 Jun 2010 17:29:00 -0000 Message-ID: In-Reply-To: <798730F0-AFFA-4812-AA49-E41A23A02D21@comcast.net> 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> From: "Paul Koning" To: "Mike Stump" , "Nathan Sidwell" Cc: "Mark Mitchell" , "Michael Matz" , "Richard Guenther" , "GCC Patches" 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/msg02478.txt.bz2 > > On 06/23/10 19:36, Mike Stump wrote: > >> C++ says: > > > > C and C++ differ in their cast-to-void behaviour. In particular, in > C++ > > (void)obj; > > does not cause a read of obj, because no lvalue->rvalue decay occurs. > This is very confusing for volatiles and incompatible with established > C semantics. As such G++ will cause a read of a volatile scalar obj in > these cases. >=20 > Yeah, this was one of the later changes that I groaned over when it > went in, I wish the C and C++ standards people were on the same page. > If they are to differ, I would not be against just making the construct > an error, to prohibit people from making any use of a semantic that > isn't the same in both languages. I know the status quo is to just > conform to the C semantic, and I didn't argue or object to that; it's > just an unfortunate position to be in. However, since we went in that > direction, I wish people would formulate a change for the C++ language > consistent with that and get that in, say, in the name of C > compatibility. As I see it, for C++ to deviate from C in this respect is a C++ bug.=20=20 Making such a construct an error in C++ programs is probably a bit strong, but I would want to see it be a warning (on by default). paul