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.
