On Wed, Feb 07, 2018 at 01:23:49PM -0500, Jason Merrill wrote:
> 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?
One of the reasons is that middle end uses poly_uint64 type but the front ends
shouldn't use them. So some of these functions will unfortunately differ.
Marek
