[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