From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21477 invoked by alias); 24 Jun 2010 15:42:56 -0000 Received: (qmail 21456 invoked by uid 22791); 24 Jun 2010 15:42:54 -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 qmta06.westchester.pa.mail.comcast.net (HELO qmta06.westchester.pa.mail.comcast.net) (76.96.62.56) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Jun 2010 15:42:48 +0000 Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta06.westchester.pa.mail.comcast.net with comcast id Zo1Q1e0040Fqzac56rioEk; Thu, 24 Jun 2010 15:42:48 +0000 Received: from c-98-210-246-208.hsd1.ca.comcast.net ([98.210.246.208]) by omta08.westchester.pa.mail.comcast.net with comcast id Zrik1e0024WWjWi3Urimja; Thu, 24 Jun 2010 15:42:47 +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: <4C231176.6050501@codesourcery.com> Date: Thu, 24 Jun 2010 17:05:00 -0000 Cc: Mark Mitchell , Michael Matz , Richard Guenther , GCC Patches Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Nathan Sidwell 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/msg02474.txt.bz2 On Jun 24, 2010, at 1:04 AM, Nathan Sidwell wrote: > On 06/23/10 19:36, Mike Stump wrote: >> C++ says: >=20 > 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. Th= is is very confusing for volatiles and incompatible with established C sema= ntics. As such G++ will cause a read of a volatile scalar obj in these cas= es. 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 p= rohibit people from making any use of a semantic that isn't the same in bot= h languages. I know the status quo is to just conform to the C semantic, a= nd I didn't argue or object to that; it's just an unfortunate position to b= e in. However, since we went in that direction, I wish people would formul= ate a change for the C++ language consistent with that and get that in, say= , in the name of C compatibility. > In C++ the result of an assignment is an lvalue. It is not in C. >=20 >> You can't just willy nilly change this: >>=20 >> int i, j, k; >> void foo(int&j) { >> foo(i =3D k); >> } >>=20 >> can sense if you get it right or not. Add a volatile on i, and you disc= over, 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. >=20 > I do not know what you are saying here. Making (just) i volatile will re= nder your code example ill-formed. Sorry for not expounding. I thought it would be obvious I was talking abou= t well formed code... First case would be something like: volatile int i, j, k; volatile int vi; void foo(volatile int& j) { foo(i =3D k); } here, we need to bind j to the address of i. The second case is something = like: volatile int i, j, k; volatile int vi; void foo(int j) { foo(i =3D k); } where the value passed to foo is the value read from i, and i being volatil= e, would mean a read of i. >> Further, C says: >>=20 >> An assignment expression has the value of the left operand after the a= ssignment >>=20 >> Now, this is pretty plain, the value is the left operand. They choose t= his 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 impl= ementors 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 th= e value that was stored in the left operand, or the value is the right oper= and after conversion to the type of the left operand, or a host of other po= ssibilities. >=20 > Are you saying that in C, both >=20 > (void)obj; > and > (void)(obj =3D value); >=20 > should behave the same wrt the behaviour of reads from a volatile obj? I= thought there was consensus that they should not. Technically, I was arguing against the dropping of the re-read of vobj in t= he a =3D vobj =3D c; case. I believe doing so would cause g++ to violate = the C++ language standard.