This is the mail archive of the
mailing list for the GCC project.
Re: Continue strict-volatile-bitfields fixes
- From: Bernd Schmidt <bernds at codesourcery dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, Joey Ye <joey dot ye at arm dot com>, "dj at redhat dot com" <dj at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "Mitchell, Mark" <mark_mitchell at mentor dot com>
- Date: Mon, 20 Feb 2012 18:28:15 +0100
- Subject: Re: Continue strict-volatile-bitfields fixes
- References: <4EBD4BCB.firstname.lastname@example.org> <4ED50901.email@example.com> <DC8FF7F4C84BE44B907369AEF21D9D446E5D368C@NA-MBX-04.mgc.mentorg.com> <4F1D72CA.firstname.lastname@example.org> <email@example.com> <CAFiYyc08w4PGPEgOGAPH0Ag_BBds_1_wLv=R-DnO+j0b7nPycQ@mail.gmail.com>
On 02/20/2012 12:14 PM, Richard Guenther wrote:
> On Fri, Feb 17, 2012 at 9:51 PM, Thomas Schwinge
> <firstname.lastname@example.org> wrote:
>> How do we move this issue forward?
>> On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt <email@example.com> 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_REFs
>>> 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.
> What about BOOLEAN_TYPE bitfields? Thus, why not explicitely
> spell out && TREE_CODE (type) == INTEGER_TYPE?
That would work for me, if we can all agree that
-fstrict-volatile-bitfields should be restricted to INTEGER_TYPE.