[C++0x] contiguous bitfields race implementation

[Richard Guenther]

On Mon, May 9, 2011 at 8:54 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, May 09, 2011 at 01:41:13PM -0500, Aldy Hernandez wrote:
>> Jakub also gave me a testcase which triggered a buglet in
>> max_field_size.  I have now added a parameter INNERDECL which is the
>> inner reference, so we can properly determine if the inner decl is
>> thread visible or not.
>
> What I meant actually was something different, if max_field_size
> and get_inner_reference was called on say
> COMPONENT_REF <ARRAY_REF <x, 4>, bitfld>
> then get_inner_reference returns the whole x and bitpos
> is the relative bit position of bitfld within the struct plus
> 4 * sizeof the containing struct.  Then
> TREE_INT_CST_LOW (TYPE_SIZE (record_type)) - bitpos
> might get negative (well, it is unsigned, so huge).
> Maybe with MEM_REF such nested handled components shouldn't appear,
> if that's the case, you should assert that somewhere.
> If it appears, you should probably use TREE_OPERAND (component_ref, 2)
> instead of bitpos.
>
> BTW, shouldn't BIT_FIELD_REF also be handled similarly to the COMPONENT_REF?
> And, probably some coordination with Richi is needed with his bitfield tree
> lowering.

Yes, we would need to handle BIT_FIELD_REFs similar (fold can introduce
them for example).  I attached a work-in-progress patch that does
bitfield lowering at the tree level.  There are interesting issues when
trying to work out the underlying object, as bitfield layout can deliberately
obfuscate things a lot.

Richard.

>        Jakub
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lower-bitfields-to-mem-ref
Type: application/octet-stream
Size: 23825 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20110510/ddacb94a/attachment.obj>