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-bugzi...@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
