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]

Re: [RFC] [tree-ssa] Fix handling of BIT_FIELD_REFs andVECTOR_TYPEs


> 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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]