On Wed, Feb 07, 2018 at 12:26:04PM -0500, Jason Merrill wrote: > On Fri, Jan 26, 2018 at 6:22 PM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Fri, Jan 26, 2018 at 02:11:19PM +0100, Richard Biener wrote: > >> >> POINTER_PLUS_EXPR offets are to be interpreted as signed (ptrdiff_t) > >> >> so using uhwi and then performing an unsigned division is wrong code. > >> >> See mem_ref_offset how to deal with this (ugh - poly-ints...). > >> >> Basically > >> >> you have to force the thing to signed. Like just use > >> >> > >> >> HOST_WIDE_INT offset = TREE_INT_CST_LOW (op01); > >> > > >> > Does it really matter here though? Any negative offsets there are UB, we > >> > should punt on them rather than try to optimize them. > >> > As we known op01 is unsigned, if we check that it fits into shwi_p, it > >> > means > >> > it will be 0 to shwi max and then we can handle it in uhwi too. > >> > >> Ah, of course. Didn't look up enough context to see what this code > >> does in the end ;) > >> > >> > /* ((foo*)&vectorfoo)[1] => BIT_FIELD_REF<vectorfoo,...> */ > >> > if (VECTOR_TYPE_P (op00type) > >> > && (same_type_ignoring_top_level_qualifiers_p > >> > - (type, TREE_TYPE (op00type)))) > >> > + (type, TREE_TYPE (op00type))) > >> > + && tree_fits_shwi_p (op01)) > >> > >> nevertheless this appearant "mismatch" deserves a comment (checking > >> shwi and using uhwi). > > > > So like this? > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > Why not use the same code as fold_indirect_ref_1 here?
That was my first patch, but it was rejected: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00271.html Marek