Hi, On Tue, Jun 12, 2012 at 03:57:44PM +0000, Jay K wrote: > > Our front end is wierd. > The input is unusually low level, and so are the trees it produces. > I do have a hankering to fix that (or maybe just to output more portable C...) > But for now: > It doesn't use component_refs, and doesn't > define types much, but uses either > either (type*)(base + offset) or bitfield_ref(base, offset, size). > > As such, it runs into occasional problems. > I have had to turn off various optimizations with e.g.: > flag_tree_sra = false > in langhook_post_options. > > Looking at this briefly, I think I see one of the problems. > tree-sra.c looks for component_refs to bitfields, but > it doesn't look for bitfield_refs. It should?
I am not sure what you mean, if you search for the sting BIT_FIELD_REF in tree-sra.c, you'll quickly find the places where we "look for" them (or perhaps I should write look through them). The most important ones are in functions build_access_from_expr_1 and especially sra_modify_expr. Having said that, Andrew Pinski has reported problems with SRA's handling of BIT_FIELD_REF in another special setup, so perhaps you have similar problems. Please have a look at the thread starting with message: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00009.html So far it however looks that, if we ever come across such problems on trunk, we'll disable SRA for aggregate parts which are written to by a BIT_FIELD_REF on a left hand side, mainly because we do not consider them important for performance critical code. Thanks, Martin
