https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125863
Drea Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
URL| |https://gcc.gnu.org/piperma
| |il/gcc-patches/2026-June/72
| |0843.html
--- Comment #2 from Drea Pinski <pinskia at gcc dot gnu.org> ---
This is interesting (for my reduced testcase in
https://gcc.gnu.org/pipermail/gcc-patches/2026-June/720843.html).
In GCC 9 (and before), evrp could figure out the ranges as:
t_5: long int ~[0, 0]
_1: long int ~[0, 0]
But starting in GCC 10 we get:
_1: long int ~[0, 0]
_2: long int [-2305843009213693952, 2305843009213693951]
a_3(D): int * VARYING
b_4(D): int * VARYING
t_5: long int [-2305843009213693952, 2305843009213693951]
But it does not matter since with my patch we get:
Global Exported: _1 = [irange] long int [-INF, -1][1, +INF]
Global Exported: t_5 = [irange] long int [-2305843009213693952, -1][1,
2305843009213693951]
Which means we can remove the trap.
And in the non-reduced testcase we can remove if here:
<bb 6> [local count: 1073741824]:
_10 = (long unsigned int) __dif_9;
if (_10 == 0)
goto <bb 7>; [33.00%]
else
goto <bb 14>; [67.00%]
