[Bug tree-optimization/97315] [11 Regression] ICE in choose_value, at gimple-ssa-evrp.c:282 since r11-3690-gebc77ce3a4c70730b4e38d68f88693eadbdc8712

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On October 7, 2020 5:35:02 PM GMT+02:00, amacleod at redhat dot com
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
>
>--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> ---
>(In reply to David Binderman from comment #6)
>> I get something similar with this test case:
>> 
>> int a;
>> void b() {
>>   if (a >= 2147483647)
>>     c(a + 1);
>> }
>
>This one is slightly different.
>
>Still triggering in the same place, but the difference in the singleton
>is the
>result of the calculation of:
>
>   [+INF, +INF] + 1
>
>EVRP is reporting  [-INF, -INF], and range-ops is calculating  [+INF,
>+INF]
>
>Is there a correct answer, or does it matter?   

While we print +inf it's just a value we can apply +1 to in the "do what I
mean" sense. So I think for arithmetic we shouldn't saturate, even when
overflow is undefined (instead as, you say, UNDEFINED would be the correct
optimistic result).

>The code we imported for handling overflow always sets the bound to
>+INF if an
>overflow happens, and it happens on both bounds, so we get  [+INF,
>+INF].  I'm
>guessing because its a single value EVRP actually folded the value
>regardless
>of overflow?   
>
>Or maybe it should be  UNDEFINED? 
>
>Andrew