[Bug tree-optimization/59417] [4.9 Regression] ICE in determine_value_range, at tree-ssa-loop-niter.c:176

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59417

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is the uninitialized var t in the testcase, with it apparently
the range info weird and inconsistent, but what sanity can one expect from
uninitialized value, any use of it is invalid.

Before *.copyprop5 we have:
  # RANGE [1, 2147483647] NONZERO 0x0000000007fffffff
  # t_4 = PHI <t_19(D)(3), t_8(23)>
(supposedly because we ignore the uninitialized var in some spots).
Then during copyprop5 we copy the range info of t_4 to t_19(D):
          else if (!POINTER_TYPE_P (TREE_TYPE (var))
                   && SSA_NAME_RANGE_INFO (var)
                   && !SSA_NAME_RANGE_INFO (copy_of[i].value))
            duplicate_ssa_name_range_info (copy_of[i].value,
                                           SSA_NAME_RANGE_TYPE (var),
                                           SSA_NAME_RANGE_INFO (var));
I'm wondering how that can be a safe thing to do, even when not taking into
account undefined vars.  If we have say:
  if (parm_5(D) < 32)
    {
      do_something_with (parm_5(D));
      goto return;
    }
  somevar_21 = parm_5(D);
and somevar_21 will have range info of [32, +INF] (from VRP ASSERT_EXPRs), then
I don't see how it can be safe to modify parm_5(D)'s SSA_NAME_RANGE_INFO
(similarly for pointer alignment info though).  For this testcase, surely we
could say avoid doing it if the copy_of[i].value SSA_NAME is default def, but I
think it is a general issue.  Perhaps points to info can be copied over, but
not alignment info or range info.  Maybe we could consider not doing copyprop
or forwprop replacing one SSA_NAME with another one if the one to be replaced
has better range info (or alignment info) and only copyprop/forwprop if we
would replace SSA_NAME with something other than SSA_NAME?

Then in tree-ssa-loop-niter.c I can surely instead of assetion failure just
give up on using the range info altogether (rtype = VR_VARYING; break;) or
just using var's range info and nothing else if there is inconsistency
(rtype = get_range_info (var, &minv, &maxv); break;).