On 18/04/12 16:37, Thomas Schwinge wrote:
> Hi!
>
> As it's been some time: this was the discussion about
> -fstrict-volatile-bitfields (as enabled by default on SH, for example)
> breaking some testsuite bits due to missed optimizations (even for
> bitfields that are not volatile).
>
> On Tue, 21 Feb 2012 09:40:07 +0000, Richard Earnshaw <rearn...@arm.com> wrote:
>> On 20/02/12 17:51, Bernd Schmidt wrote:
>>> On 02/20/2012 06:39 PM, Richard Earnshaw wrote:
>>>> 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.
>>>
>>> What are your thoughts on the argument about enums?
>>
>> Similar. A particular enumeration type has a defined size, so accesses
>> should use that size.
>
> In that case, would it be appropriate to apply the following?
>
> gcc/testsuite/
> * gcc.dg/tree-ssa/20030922-1.c: Compile with
> -fno-strict-volatile-bitfields.
> * gcc.dg/tree-ssa/foldconst-3.c: Likewise.
> * gcc.dg/tree-ssa/vrp15.c: Likewise.
>
None of these have any volatile bitfields, so the option should be a no-op.
