[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:b9475357b5b180c63b3389742452a48026f073a6

commit r10-8494-gb9475357b5b180c63b3389742452a48026f073a6
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Jul 14 19:24:56 2020 +0100

    value-range: Fix handling of POLY_INT_CST anti-ranges [PR96146]

    The range infrastructure has code to decompose POLY_INT_CST ranges
    to worst-case integer bounds.  However, it had the fundamental flaw
    (obvious in hindsight) that it applied to anti-ranges too, meaning
    that a range 2+2X would end up with a range of ~[2, +INF], i.e.
    [-INF, 1].  This patch decays to varying in that case instead.

    I'm still a bit uneasy about this.  ISTM that in terms of
    generality:

      SSA_NAME => POLY_INT_CST => INTEGER_CST
               => ADDR_EXPR

    I.e. an SSA_NAME could store a POLY_INT_CST and a POLY_INT_CST
    could store an INTEGER_CST (before canonicalisation).  POLY_INT_CST
    is also âas constant asâ ADDR_EXPR (well, OK, only some ADDR_EXPRs
    are run-time rather than link-time constants, whereas all POLY_INT_CSTs
    are, but still).  So it seems like we should at least be able to treat
    POLY_INT_CST as symbolic.  On the other hand, I don't have any examples
    in which that would be useful.

    gcc/
            PR tree-optimization/96146
            * value-range.cc (value_range::set): Only decompose POLY_INT_CST
            bounds to integers for VR_RANGE.  Decay to VR_VARYING for
anti-ranges
            involving POLY_INT_CSTs.

    gcc/testsuite/
            PR tree-optimization/96146
            * gcc.target/aarch64/sve/acle/general/pr96146.c: New test.