This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] fix wrong-code bug for -fstrict-volatile-bitfields
On 2012/8/23 05:08, Richard Guenther wrote:
>> First of all the warning should be probably issued from stor-layout.c
>> itself - see
>> other cases where we warn about packed structs. Yes, that means you'll
>> get the warning even when there is no access but you'll only get it a
>> single time.
>>
>> As of detecting whether a field is not aligned according to its mode, well,
>> that's impossible if you just look at the field or its containing type (and thus
>> for a warning without false positives / negatives from stor-layout). It's also
>> impossible to determine optimally (thus, it will say "not aligned according to
>> its mode" in more cases). The way you detect such misalignment is,
>> given an access to such field,
>>
>> get_object_alignment (exp) < GET_MODE_ALIGNMENT (DECL_MODE (field))
>>
>> when exp is a COMPONENT_REF with TREE_OPERAND (exp, 1) == field
>> and field has non-BLK mode.
>>
>> Note that an access a.f with f being a volatile field may be represented
>> by a volatile MEM_REF[&a, 16] where 16 is the byte offset relative to a.
WRT only the code expansion aspects in store_fixed_bit_field(), would a
test of "STRICT_ALIGNMENT && MEM_ALIGN(op0) < GET_MODE_ALIGNMENT(mode)"
be sufficient to detect instead of a packedp parameter?
Chung-Lin
>> Now, if you are only interested in bitfields (note, bitfields which fit a mode
>> are _not_ bitfields as far as optimization passes are concerned and thus
>> may end up like above), then you probably want to look at
>> DECL_BIT_FIELD_REPRESENTATIVE of the FIELD_DECL of such field.
>> DECL_BIT_FIELD_REPRESENTATIVE constrains the offset / size said
>> field is to be accessed and you should call get_object_alignment with
>> a COMPONENT_REF using that field instead. You also want to make
>> sure DECL_BIT_FIELD_REPRESENTATIVE is computed correctly for
>> volatile bitfields on ARM (stor-layout computes that).
>
> In fact, you should probably implement code-generation constraints from
> within the frontends by, for strict volatile bitfields, emitting loads/stores
> using DECL_BIT_FIELD_REPRESENTATIVE (doing read-modify-write
> explicitely). Or maybe you can elaborate on the code-generation effects
> of strict-volatile bitfields?