This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++0x] contiguous bitfields race implementation


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
>

Attachment: lower-bitfields-to-mem-ref
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]