On Wed, Feb 7, 2018 at 12:54 PM, Marek Polacek <pola...@redhat.com> wrote: > 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
Then should we update fold_indirect_ref_1 to use the new code? Is there a reason for them to stay out of sync? Jason