On Thu, Jan 30, 2020 at 2:04 PM Bin.Cheng <amker.ch...@gmail.com> wrote: > > On Thu, Jan 30, 2020 at 8:53 PM Andrew Stubbs <a...@codesourcery.com> wrote: > > > > On 29/01/2020 08:24, Richard Biener wrote: > > > On Tue, Jan 28, 2020 at 5:53 PM Andrew Stubbs <a...@codesourcery.com> > > > wrote: > > >> > > >> This patch fixes an ICE compiling fast-math-pr55281.c for amdgcn. > > >> > > >> The problem is that an "iv" is created in which both base and step are > > >> pointer types, > > > > > > How did you get a POINTER_TYPE step? That's where the issue lies > > > I think. > > > > It can come from "find_inv_vars_cb": > > > > set_iv (idata, op, op, build_int_cst (TREE_TYPE (op), 0), true); > > This is recording invariant with zero step. It seems we are using > wrong type building the zero-step. How about detecting that op has > pointer type and using integer type here?
that sounds like a good idea. > Thanks, > bin > > > > whenever "op" has a pointer type. > > > > Similarly for "get_iv": > > > > set_iv (data, var, var, build_int_cst (type, 0), true); > > > > whenever "var" has a pointer type. > > > > In this particular case, I traced the origin back to the second one, I > > think (but it's somewhat hard to unpick). > > > > I could change one or both of those, but I don't understand enough about > > the consequences of that to be sure it's the right thing to do. I can > > confirm that converting the step at this point does appear to have the > > desired effect in this instance. > > > > At least at the point of writing it to gimple I can determine what is > > definitely malformed. > > > > Andrew
