https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96146
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Richard Sandiford <rsand...@gcc.gnu.org>: https://gcc.gnu.org/g:505032d97d0593d5e9a6f51b107650e27fcf6b23 commit r11-2034-g505032d97d0593d5e9a6f51b107650e27fcf6b23 Author: Richard Sandiford <richard.sandif...@arm.com> Date: Sat Jul 11 13:25:26 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.
