From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4082 invoked by alias); 18 Apr 2012 16:16:58 -0000 Received: (qmail 3942 invoked by uid 22791); 18 Apr 2012 16:16:54 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Apr 2012 16:16:22 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Wed, 18 Apr 2012 17:14:21 +0100 Received: from [10.1.69.67] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Apr 2012 17:15:20 +0100 Message-ID: <4F8EE84C.20501@arm.com> Date: Wed, 18 Apr 2012 16:16:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Thomas Schwinge CC: Bernd Schmidt , Richard Guenther , Joey Ye , "dj@redhat.com" , GCC Patches , "Mitchell, Mark" Subject: Re: Continue strict-volatile-bitfields fixes References: <4EBD4BCB.4080807@codesourcery.com> <4ED50901.8090300@codesourcery.com> <4F1D72CA.1060908@codesourcery.com> <874nupb2v4.fsf@schwinge.name> <4F4282AF.7000804@codesourcery.com> <4F428565.1050508@arm.com> <4F42881B.80800@codesourcery.com> <4F436677.9090203@arm.com> <87obqpnj9i.fsf@schwinge.name> In-Reply-To: <87obqpnj9i.fsf@schwinge.name> X-MC-Unique: 112041817142122701 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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: 2012-04/txt/msg01095.txt.bz2 On 18/04/12 16:37, Thomas Schwinge wrote: > Hi! >=20 > As it's been some time: this was the discussion about > -fstrict-volatile-bitfields (as enabled by default on SH, for example) > breaking some testsuite bits due to missed optimizations (even for > bitfields that are not volatile). >=20 > On Tue, 21 Feb 2012 09:40:07 +0000, Richard Earnshaw w= rote: >> On 20/02/12 17:51, Bernd Schmidt wrote: >>> On 02/20/2012 06:39 PM, Richard Earnshaw wrote: >>>> I'm not sure why it should be. Can't a user write >>>> >>>> #ifdef __cplusplus >>>> #define BOOL bool >>>> #else >>>> #define bool _Bool >>>> #endif >>>> >>>> struct x { >>>> volatile BOOL a : 1; >>>> volatile BOOL b : 1; >>>> volatile unsigned char c : 6; >>>> volatile BOOL d : 1; >>>> } y; >>>> >>>> ? >>>> >>>> If you've got strict volatile bitfields, then the concept here is that >>>> the access uses the declared type for accessing the member. Since in >>>> the ABI bool has a defined size, then it should access the member using >>>> that size. >>>> >>>> On ARM, sizeof bool is 1, so I'd take the above to mean that accessing >>>> y.a to mean a read of a, b and c, but not d. >>> >>> What are your thoughts on the argument about enums? >> >> Similar. A particular enumeration type has a defined size, so accesses >> should use that size. >=20 > In that case, would it be appropriate to apply the following? >=20 > gcc/testsuite/ > * gcc.dg/tree-ssa/20030922-1.c: Compile with > -fno-strict-volatile-bitfields. > * gcc.dg/tree-ssa/foldconst-3.c: Likewise. > * gcc.dg/tree-ssa/vrp15.c: Likewise. > None of these have any volatile bitfields, so the option should be a no-op.