https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #41 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 9 Jan 2019, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739 > > --- Comment #38 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot > gnu.org> --- > Created attachment 45392 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45392&action=edit > patch that changes get_ref_base_and_extent for bare SSA_NAMEs > > (In reply to Wilco from comment #37) > > (In reply to rsand...@gcc.gnu.org from comment #35) > > > Yeah, the expr.c patch makes the original testcase work, but we still fail > > > for: > > > > That's the folding in ccp1 after inlining, which will require a similar fix. > > There are likely more places that need to be fixed to handle the 'short' bit > > types. > > Yeah, seems like a can of worms. > > The expr.c approach treats a reference to an N-bit integer in an > M>N-bit mode is relative to M rather than N (i.e. it's relative > to the addressable storage.) So maybe the point this goes wrong > is when we ask for get_ref_base_and_extent on a bare 30-bit SSA_NAME > (no component accesses) and get back an offset of 0. If everything's > relative to the addressable storage then maybe it should be 2 for > big-endian? > > The attached patch does that and seems to pass all three tests > in the PR so far. I'll give a spin overnight just in case > it's at least vaguely sensible. I considered this. I guess we need to document this somewhere though. Incidentially the GIMPLE verifier already does if (!AGGREGATE_TYPE_P (TREE_TYPE (op)) && maybe_gt (size + bitpos, tree_to_poly_uint64 (TYPE_SIZE (TREE_TYPE (op))))) { error ("position plus size exceeds size of referenced object in " "BIT_FIELD_REF"); return true; } so it uses TYPE_SIZE and not TYPE_PREICISON to verify the bounds of the BIT_FIELD_REF access. That said we should probably have exhaustive testing on this. Maybe simply try to add GIMPLE testcases exercising the BIT_FIELD_REF of bit-precision entities case. I also wonder whether for the GIMPLE checking we want to verify that for bit-precision OP the extracted range is within what is valid (which depends on endianess then?).
