https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97457
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
CC| |rsandifo at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2020-10-27
--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
Ugh. This is yet another problem with calculating value ranges
for POLY_INT_CSTs. We have:
ivtmp_76 = ASSERT_EXPR <ivtmp_60, ivtmp_60 > POLY_INT_CST [9, 4294967294]>
where the VQ coefficient is unsigned but is effectively acting
as a negative number. We wrongly give the POLY_INT_CST the range:
[9, INT_MAX]
and things go downhill from there.
I guess this is the final nail in the coffin for doing VRP on
POLY_INT_CSTs. :-( For other similarly exotic testcases we could
have overflow for any coefficient, not just those that could
be treated as contextually negative.
Let's see what the fallout is from removing the code...
