https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #42 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #41) > 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 [details] > > --> 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? Btw, get_inner_reference should be changed the same way, likewise eventually get_addr_base_and_unit_offset. > > 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?).
