https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173
--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> --- "So I take the other way around by passing the IV's ssa_name into scev_probably_wraps_p along call sequence "idx_find_step->convert_affine_scev->scev_probably_wraps". Since the IV's ssa_name is tagged with right range information, we can use it when proving there is no overflow/wrap in src scev." I'm not sure that this is always correct - is the name we ask scev_probably_wraps on always equal to the IV? Is it never offsetted? I think that we need a soultion that involves tracking of range information all the way through SCEV analysis and thus have it on the CHREC itself. As for the other things - yes, there are multiple places where we lose sign information and STEP is just one example (I _think_ I made DR_STEP for data-ref analysis forced signed at some point). Promoting the array index to a word_mode type sounds interesting, it of course only makes sense for previously signed types - otherwise you just get another conversion in the way. Of course with GCC you will likely run into the issue that this promotion is cancelled by the forced conversion to sizetype, so you'll end up with unsigned word_mode again. Btw - this was kind of my suggestion with making get_inner_reference return *POFFSET as ssizetype type, not sizetype (callers might not expect this, so for experimenting just wrap get_inner_reference in sth converting that back to sizetype for all callers but IVOPTs and tree-affine.c (and eventually tree-scalar-evolution.c)).
