https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125186
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|120763 |
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org
Last reconfirmed| |2026-05-11
Status|UNCONFIRMED |NEW
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
As expected this is a costing overflow. Essentially the param value causes the
cost of a VEC_DUPLICATE to overflow to a negative value. In gcse.c we
multiply that cost by a distance to produce a "max_distance". We then assert
the max_distance is non-negative.
At some level these overflows are going to be pervasive. For example we can
almost certainly crank up param_gcse_cost_distance_ratio to a similar number
and see similar behavior. Similarly we can get into an overflow situation as a
result of multiply the two params.
Point being I strongly suspect fuzzing values for these costing parameters
would likely hit all kinds of overflow scenarios and we need to be more robust
even if we can't reasonably prevent the overflow.
My thinking right now is to clamp the gpr2vr cost to something like 20 or 30.
THat would likely fix this instances, but I don't doubt we can find more
overflow problems with params that take integer arguments.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
[Bug 120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting
