Eric Botcazou <ebotca...@adacore.com> 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) but not the
>> volatility restrictions (also a correctness issue). Especially when the
>> interface already knows whether the field is volatile and already handles
>> the choice between "narrow" and "wide" volatile bitfields.
>
> Richard B.'s idea is precisely to reimplement -fstrict-volatile bitfields on
> top of bitregion_{start,end}, that's why I'm not sure we want to make it part
> of the interface at all.
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 do I need to add new code to the expmed.c routines?
Richard
