This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Continue strict-volatile-bitfields fixes
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Bernd Schmidt <bernds at codesourcery dot com>, "Schmidt, Bernd" <Bernd_Schmidt at mentor 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 12:14:57 +0100
- Subject: Re: Continue strict-volatile-bitfields fixes
- Authentication-results: mr.google.com; spf=pass (google.com: domain of richard.guenther@gmail.com designates 10.50.57.234 as permitted sender) smtp.mail=richard.guenther@gmail.com; dkim=pass header.i=richard.guenther@gmail.com
- References: <4EBD4BCB.4080807@codesourcery.com> <4ED50901.8090300@codesourcery.com> <DC8FF7F4C84BE44B907369AEF21D9D446E5D368C@NA-MBX-04.mgc.mentorg.com> <4F1D72CA.1060908@codesourcery.com> <874nupb2v4.fsf@schwinge.name>
On Fri, Feb 17, 2012 at 9:51 PM, Thomas Schwinge
<thomas@codesourcery.com> wrote:
> Hi!
>
> How do we move this issue forward?
>
> On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt <bernds@codesourcery.com> 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.
>> >
>> > If you don't hear any objections within a week, please proceed.
>>
>> 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.
>> Thomas has tested this on arm and sh with our internal tree.
>>
>>
>> Bernd
>>
>>
>> Index: gcc/stor-layout.c
>> ===================================================================
>> --- 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) != 0
>> ? ? ? ? ? ? && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
>> - ? ? ? ? ? && GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT
>> - ? ? ? ? ? && flag_strict_volatile_bitfields <= 0)
>> + ? ? ? ? ? && GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT)
>> ? ? ? ? ? {
>> ? ? ? ? ? ? enum machine_mode xmode
>> ? ? ? ? ? ? ? = mode_for_size_tree (DECL_SIZE (decl), MODE_INT, 1);
>> @@ -674,7 +673,12 @@
>>
>> ? ? ? ? ? ? if (xmode != BLKmode
>> ? ? ? ? ? ? ? ? && !(xalign > BITS_PER_UNIT && DECL_PACKED (decl))
>> - ? ? ? ? ? ? ? && (known_align == 0 || known_align >= xalign))
>> + ? ? ? ? ? ? ? && (known_align == 0 || known_align >= xalign)
>> + ? ? ? ? ? ? ? ? ?&& (flag_strict_volatile_bitfields <= 0
>> + ? ? ? ? ? ? ? ? ? ? ?/* Same size makes strict volatile bitfields
>> meaningless. ?*/
>> + ? ? ? ? ? ? ? ? ? ? ?|| GET_MODE_SIZE (xmode) == GET_MODE_SIZE
>> (TYPE_MODE (type))
>> + ? ? ? ? ? ? ? ? ? ? ?/* Strict volatile bitfields shouldn't apply to
>> enums. ?*/
>> + ? ? ? ? ? ? ? ? ? ? ?|| TREE_CODE (type) == ENUMERAL_TYPE))
What about BOOLEAN_TYPE bitfields? Thus, why not explicitely
spell out && TREE_CODE (type) == INTEGER_TYPE?
>> ? ? ? ? ? ? ? {
>> ? ? ? ? ? ? ? ? DECL_ALIGN (decl) = MAX (xalign, DECL_ALIGN (decl));
>> ? ? ? ? ? ? ? ? DECL_MODE (decl) = xmode;
>>
>
>
> Grüße,
> ?Thomas