Eric Botcazou writes:
>> OK. The current recursive force-mem-to-reg cases in store_bit_field_1
>> and extract_bit_field_1 don't handle -fstrict-volatile-bitfields at all,
>> so this patch was trying to fix what seemed like an oversight. Is it OK
>> to leave the code as-is (not handling -fstrict-
> OK. The current recursive force-mem-to-reg cases in store_bit_field_1
> and extract_bit_field_1 don't handle -fstrict-volatile-bitfields at all,
> so this patch was trying to fix what seemed like an oversight. Is it OK
> to leave the code as-is (not handling -fstrict-volatile-bitfields),
> or d
Eric Botcazou writes:
>> The idea was to centralise the knowledge about what modes are valid
>> rather than requiring every client to know the rules. From that point
>> of view it seems inconsistent for the new interface to handle the
>> bitregion_{start,end} restrictions (a correctness issue) bu
> The idea was to centralise the knowledge about what modes are valid
> rather than requiring every client to know the rules. From that point
> of view it seems inconsistent for the new interface to handle the
> bitregion_{start,end} restrictions (a correctness issue) but not the
> volatility rest
Thanks for the reviews.
Eric Botcazou writes:
>> This patch makes bit_field_mode_iterator take -fstrict-volatile-bitfields
>> into account, in cases where the size of the underlying object is known.
>> This is used in the next patch.
>
> Do we really need to add that to the iterator? The -fstric
> This patch makes bit_field_mode_iterator take -fstrict-volatile-bitfields
> into account, in cases where the size of the underlying object is known.
> This is used in the next patch.
Do we really need to add that to the iterator? The -fstrict-volatile-
bitfields implementation is still controve
