From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1876 invoked by alias); 20 Feb 2012 17:40:31 -0000 Received: (qmail 1858 invoked by uid 22791); 20 Feb 2012 17:40:30 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,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; Mon, 20 Feb 2012 17:39:57 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 20 Feb 2012 17:39:55 +0000 Received: from [10.1.69.67] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Feb 2012 17:40:06 +0000 Message-ID: <4F428565.1050508@arm.com> Date: Mon, 20 Feb 2012 18:10:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Bernd Schmidt CC: Richard Guenther , Thomas Schwinge , 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> In-Reply-To: <4F4282AF.7000804@codesourcery.com> X-MC-Unique: 112022017395501101 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-02/txt/msg01017.txt.bz2 On 20/02/12 17:28, Bernd Schmidt wrote: > On 02/20/2012 12:14 PM, Richard Guenther wrote: >> On Fri, Feb 17, 2012 at 9:51 PM, Thomas Schwinge >> wrote: >>> Hi! >>> >>> How do we move this issue forward? >>> >>> On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt wrote: >>>> That was committed a while ago. The part in stor-layout.c that stops us >>>> from promoting bitfields to normal fields apparently caused some >>>> testsuite regressions in sh tests, where some optimization dump scans >>>> show that we can't perform the optimizations if there are BIT_FIELD_RE= Fs >>>> rather than a normal member access. >>>> >>>> The testcases use things like >>>> enum something field:8; >>>> and I think applying strict-volatile-bitfields to enums is probably >>>> meaningless. Should we adjust semantics so that the compiler is free to >>>> optimize enum bitfields? The patch would look something like the below. >=20 >> >> What about BOOLEAN_TYPE bitfields? Thus, why not explicitely >> spell out && TREE_CODE (type) =3D=3D INTEGER_TYPE? >=20 > That would work for me, if we can all agree that > -fstrict-volatile-bitfields should be restricted to INTEGER_TYPE. >=20 >=20 > Bernd >=20 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. R.