On Mon, May 9, 2011 at 8:54 PM, Jakub Jelinek <ja...@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 >
lower-bitfields-to-mem-ref
Description: Binary data
