[RFC] [tree-ssa] Fix handling of BIT_FIELD_REFs andVECTOR_TYPEs
Paolo Bonzini
bonzini@gnu.org
Mon Mar 22 18:11:00 GMT 2004
> I *think* I've seen BIT_FIELD_REFs on the LHS of assignments and we were
> DTRT, because the variable was already marked non-gimple. So, it seems
> to me that just marking VECTOR_TYPE as non-gimple ought to suffice.
Translated to code? :-)
This may be even better actually because VECTOR_TYPEs are not needed to use
VOPS until the lowering pass, and then only if the BIT_FIELD_REFs are really
generated. I can mark the variable that was subject to lowering as
non-gimple.
> If you have time, could you insert a probe in verify_stmts to abort when
> we see BIT_FIELD_REF on the LHS of an assignment? I'm almost sure you
> will hit it in a typical bootstrap.
I'll check it out. But to trigger the bug you need *two consecutive*
BIT_FIELD_REFs. I'll see if I can construct a testcase, though it seems quite
hard.
> That would be a good check to add to verify_stmts, BTW. Making sure
> that BIT_FIELD_REF operands are non-gimple variables.
I'll try adding that.
>> * tree-alias-common.c (find_func_aliases): Handle
>> MODIFY_EXPRs where the first operand is a BIT_FIELD_REF.
>> * tree-simple.c: Document that a BIT_FIELD_REF is a
>> valid GIMPLE lvalue.
>> * tree-ssa-operands.c (get_expr_operands): Glob references
>> made through BIT_FIELD_REF.
>> * tree-ssa.c (set_is_used): Go through BIT_FIELD_REFs.
Dan commented on the first one. The second one seems obvious. What about the
other two, especially if I can build a testcase?
Paolo
More information about the Gcc-patches
mailing list