https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122215
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at redhat dot com
--- Comment #12 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Vlad, I'm chasing this bug and hoping that the valgrind out of bounds/uninit
read in IRA is ultimately going to be the root cause. I could use a little
guidance on how this is supposed to work.
IRA has a costs array. It's initialized inside init_costs, yet there's two
callers to init_costs. One is via ira_set_pseudo_classes where
cost_elements_num is set from max_reg_num in ira_set_pseudo_classes.
The other (more worrisome) call via ira_costs where cost_elements_num is set
from ira_allocnos_num.
We have this code in improve_allocation:
/* Now we choose hard register for A which results in highest
allocation cost improvement. */
for (j = 0; j < class_size; j++)
{
hregno = ira_class_hard_regs[aclass][j];
if (check_hard_reg_p (a, hregno,
conflicting_regs, profitable_hard_regs)
&& min_cost > costs[hregno])
{
best = hregno;
min_cost = costs[hregno];
}
}
If I'm understanding things correctly, ira_class_hard_regs contains a list of
hard registers available for each register class. So if the number of allocnos
is less than the number of hard registers, then we can do an out of bounds read
on the costs[] array. Depending on the precise value we read, we can
utlimately change the allocation resulting in sporatic changes in the generated
code.
Am I missing something fundamental about how this is supposed to work?
