https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119872
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
Last reconfirmed| |2025-04-21
--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
Thanks for the report.
This is happening because we're using the affine tree at the same precision as
the type of the expression. This means that on overflow the values truncate
which leads to IVopts combining the wrong IVs.
e.g. it thinks that these two aren't a multiple of eachother
>>> p debug (top)
(prephitmp_126 + -282547080) * 36
>>> p debug (bot)
(unsigned int) (prephitmp_126 + -282547080)
because 36 * -282547080 overflows a 32-bit int.
There are two possible fixes here and I'll regtest both and see which one the
release managers want.
1. Go back to the old code and use OEP_ASSUME_WRAPV in operand_equal_p.
2. Keep the affine tree comparison, but use a type that's twice the precision
of the input to account for any possible overflows.
Both fix the error and keep the structural comparison that we need.
The original code in IVops never actually did the multiply. so it never
overflowed, but also wouldn't see (prephitmp_126 + -282547080) * 36 and
(prephitmp_126 + -282547080) * 6 * 6 as being equal so no #2 seems like the
better solution.
