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] |
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] |