[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code

[rguenth at gcc dot gnu dot org]

------- Comment #47 from rguenth at gcc dot gnu dot org  2008-03-28 22:12 -------
What is interesting is that j__target_type___XDLU_10__20 is a unsigned sub type
with range [10, 20] of a signed base type with range [-128, 127].  So, we
enter compare_values ((js__TtB)20, (j__target_type___XDLU_10__20)128)
(both types have a precision of 8 bits, but the out-of-range value 128 is
not representable in the base type, but is interpreted as -128).

So, why is this range check

  if (target_first_66 == 128)
    goto <bb 7>;
  else
    goto <bb 8>;

<bb 7>:
  __gnat_rcheck_12 ("join_equal.adb", 15);

using a value not representable in the base type?  The TYPE_MIN/MAX_VALUEs
are of the type of the base type, so target_first_66s value range is
[10, 20] at the point of this comparison.  Is this supposed to be
a comparison with -128 or with 128?  That is, is this

  target_first_66 == TYPE_MIN_VALUE (js__TtB)

?  I guess so.

The problem is that we try to compare different typed values here, the
10 and 20 of signed base type and the 128 of unsigned sub type.  If
we for the comparison canonicalize the 128 to the signed base type
(which is the only thing that makes sense) we get an overflow value
as it wraps to -128 and the comparison result will be ignored because
"it assumes that signed overflow is undefined".  Bah.

So let's try avoiding setting the overflow flag for conversions from
a sub type to its base type.  Then I have a patch that evaluates

      target_first_66 == 128

to false based on the initial value range idea for default SSA_NAMEs
and the only remaining range checks are

grep gnat_rcheck j.ads.127t.optimized 
  __gnat_rcheck_04 ("join_equal.adb", 13);
  __gnat_rcheck_12 ("join_equal.adb", 29);
  __gnat_rcheck_12 ("join_equal.adb", 39);


-- 


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