From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27061 invoked by alias); 17 Feb 2012 20:51:47 -0000 Received: (qmail 27051 invoked by uid 22791); 17 Feb 2012 20:51:46 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Feb 2012 20:51:29 +0000 Received: from nat-dem.mentorg.com ([195.212.93.2] helo=eu2-mail.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RyUm7-0005s7-Tj from Thomas_Schwinge@mentor.com ; Fri, 17 Feb 2012 12:51:28 -0800 Received: from feldtkeller.schwinge.homeip.net ([172.30.64.200]) by eu2-mail.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Feb 2012 21:51:26 +0100 From: Thomas Schwinge To: Bernd Schmidt Cc: "Schmidt\, Bernd" , Joey Ye , "dj\@redhat.com" , GCC Patches , "Mitchell\, Mark" Subject: Re: Continue strict-volatile-bitfields fixes In-Reply-To: <4F1D72CA.1060908@codesourcery.com> References: <000801cca086$dcd59b30$9680d190$@ye@arm.com> <4EBD4BCB.4080807@codesourcery.com> <4ED50901.8090300@codesourcery.com> <4F1D72CA.1060908@codesourcery.com> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Fri, 17 Feb 2012 20:57:00 -0000 Message-ID: <874nupb2v4.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" 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/msg00965.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2652 Hi! How do we move this issue forward? On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt = wrote: > On 11/29/2011 05:35 PM, Mitchell, Mark wrote: > >>> So, I still think this patch is the best way to go forward, and it > >> does > >>> fix incorrect code generation. Would appreciate an OK. > >> > >> Ping. > >=20 > > If you don't hear any objections within a week, please proceed. >=20 > 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_REFs > rather than a normal member access. >=20 > 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. > Thomas has tested this on arm and sh with our internal tree. >=20 >=20 > Bernd >=20 >=20 > Index: gcc/stor-layout.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- gcc/stor-layout.c (revision 355696) > +++ gcc/stor-layout.c (working copy) > @@ -665,8 +665,7 @@ > may make a volatile object later. */ > if (TYPE_SIZE (type) !=3D 0 > && TREE_CODE (TYPE_SIZE (type)) =3D=3D INTEGER_CST > - && GET_MODE_CLASS (TYPE_MODE (type)) =3D=3D MODE_INT > - && flag_strict_volatile_bitfields <=3D 0) > + && GET_MODE_CLASS (TYPE_MODE (type)) =3D=3D MODE_INT) > { > enum machine_mode xmode > =3D mode_for_size_tree (DECL_SIZE (decl), MODE_INT, 1); > @@ -674,7 +673,12 @@ >=20 > if (xmode !=3D BLKmode > && !(xalign > BITS_PER_UNIT && DECL_PACKED (decl)) > - && (known_align =3D=3D 0 || known_align >=3D xalign)) > + && (known_align =3D=3D 0 || known_align >=3D xalign) > + && (flag_strict_volatile_bitfields <=3D 0 > + /* Same size makes strict volatile bitfields > meaningless. */ > + || GET_MODE_SIZE (xmode) =3D=3D GET_MODE_SIZE > (TYPE_MODE (type)) > + /* Strict volatile bitfields shouldn't apply to > enums. */ > + || TREE_CODE (type) =3D=3D ENUMERAL_TYPE)) > { > DECL_ALIGN (decl) =3D MAX (xalign, DECL_ALIGN (decl)); > DECL_MODE (decl) =3D xmode; >=20 Gr=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 489 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJPPr3AAAoJENuKOtuXzphJEDUH/iCp08rCqiBRZ5nkZ2rAOmMV XruIOOHwdt985l1oyEtGY9itvE0LOTkNy5bvQmyywgzmmgoPn/ePcNttkFoirN6t wWBg+36LMTMXE+McGf+G/ItspBW0tFUc5vAR877T3mxJ2gmT7VpLQa/SR56xZwuC gzKioa5ltM8L0SdgAIyL03c30pKJyoxLX0Sf6lqtqL3Xu4LnA4zZPqthziSeO++B ayaJh/K9HI37F4zuJ636p+xeTBNMUwXSIHDAkIJOtqmGh6WmZrt2571nLyWILbh1 jHlJAeVp3SvEEHqTWaZ6T0duB4nSx61XqRHd+8ig3owL60QZXgZ8Ztp3B7O47AI= =XY/0 -----END PGP SIGNATURE----- --=-=-=--