On Fri, Jun 1, 2012 at 6:02 AM, Andrew Pinski <andrew.pin...@caviumnetworks.com> wrote: > Hi, > When I modified GCC to change the majority of bitfield accesses > which were done via component ref to BIT_FIELD_REF, SRA messes up > because when it does the replacement it still tries to use the > BIT_FIELD_REF except it never places the old value in the struct for > the BIT_FIELD_REF to work correctly. > > This patch fixes the problem by expanding what BIT_FIELD_REF does > internally for both writing and reading. Note we can't use > BIT_FIELD_REF directly on the left hand since we don't support partial > writes yet (except for vector and complex types). > > This is only a RFC since I don't know a way to reproduce this bug on > the trunk. I tested it on x86_64-linux-gnu with no regressions.
I'd rather disqualify SRA of BIT_FIELD_REFs on the LHS for now. My goal was to enable SRA of bitfields using the DECL_BIT_FIELD_REPRESENTATIVE work - something you go against with replacing them with BIT_FIELD_REFs. You'd replace x = a.b; with tem = a.<representative for b>; x = BIT_FIELD_REF <tem, ....>; and for stores with a read-modify-write sequence, possibly adding the bitfield-insert tree I proposed some time ago. Replace a.b = x; with tem = a.<representative for b> tem = BIT_FIELD_EXPR <tem, x, ...>; a.<representative for b> = tem; and I'd do this replacement in SRA for now whenever it would decide to SRA a bitfield. Richard. > Thanks, > Andrew Pinski > > ChangeLog: > * tree-sra.c (sra_modify_expr): Handle BIT_FIELD_REF specially if we > are doing a replacement of the struct with one variable.
