On 20/02/12 17:28, Bernd Schmidt wrote:
> On 02/20/2012 12:14 PM, Richard Guenther wrote:
>> On Fri, Feb 17, 2012 at 9:51 PM, Thomas Schwinge
>> <tho...@codesourcery.com> wrote:
>>> Hi!
>>>
>>> How do we move this issue forward?
>>>
>>> On Mon, 23 Jan 2012 15:46:34 +0100, Bernd Schmidt <ber...@codesourcery.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.
>
>
> Bernd
>
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.
R.
