[Bug c/111303] ICE: in type, at value-range.h:869

2023-09-06 Thread shaohua.li at inf dot ethz.ch via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303

Shaohua Li  changed:

   What|Removed |Added

 CC||guojiufu at gcc dot gnu.org

--- Comment #1 from Shaohua Li  ---
Bisected to r14-3644-g1aceceb1e2

[Bug c/111303] ICE: in type, at value-range.h:869

2023-09-06 Thread guojiufu at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303

Jiu Fu Guo  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |guojiufu at gcc dot 
gnu.org

--- Comment #2 from Jiu Fu Guo  ---
Thanks for reporting this!

[Bug c/111303] ICE: in type, at value-range.h:869

2023-09-06 Thread guojiufu at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303

Jiu Fu Guo  changed:

   What|Removed |Added

   Last reconfirmed||2023-09-06
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c/111303] ICE: in type, at value-range.h:869

2023-09-06 Thread guojiufu at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303

--- Comment #3 from Jiu Fu Guo  ---
In the pattern of match.pd, there is:

  && range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1)
  && get_range_query (cfun)->range_of_expr (vr3, @3)
  /* "X+C" and "X" are not of opposite sign.  */
  && (TYPE_UNSIGNED (type)
  || (vr0.nonnegative_p () && vr3.nonnegative_p ())
  || (vr0.nonpositive_p () && vr3.nonpositive_p (


For this case, "vr3" is "undefined_p", then "vr3.nonnegative_p ()" trige ICE.

Checking "!vr3.undefine_p ()" would be a safe fix for this ICE.

[Bug c/111303] ICE: in type, at value-range.h:869

2023-09-06 Thread guojiufu at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303

--- Comment #4 from Jiu Fu Guo  ---
For the pattern: "(X + C) / N", "op (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)"
where "X" has value-range, and "X + C" does not overflow:

&& get_range_query (cfun)->range_of_expr (vr0, @0))
&& get_range_query (cfun)->range_of_expr (vr1, @1)
&& range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1)

Then "@3"(it is X+C) would be with value-range usually.
But for particular cases, like this PR, "vr3" is undefined. 
Below would be the reason for why "vr3" is undefined:


_3 = _2 + -5;
if (0 != 0)
  goto ; [34.00%]
else
  goto ; [66.00%]
;;  succ:   3
;;  4

;; basic block 3, loop depth 0
;;  pred:   2
_5 = _3 / 5; 
;;  succ:   4

The whole pattern "(_2 + -5 ) / 5" is in "bb 3", but "bb" would be unreachable
(because "if (0 != 0)" is always false).
And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in "bb 3",
"range_of_expr" gets an "undefined vr3".