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))
{
DECL_ALIGN (decl) = MAX (xalign, DECL_ALIGN (decl));
DECL_MODE (decl) = xmode;
