[Bug c/111303] ICE: in type, at value-range.h:869
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
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
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
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
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".