https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119706
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. We have a POLY_INT_CST in the base address of a TARGET_MEM_REF:
MEM <vector([2,2]) double> [(double *)POLY_INT_CST [16B, 16B] + ivtmp_97 * 8]
but is_gimple_mem_ref_addr only allows:
bool
is_gimple_mem_ref_addr (tree t)
{
return (is_gimple_reg (t)
|| TREE_CODE (t) == INTEGER_CST
|| (TREE_CODE (t) == ADDR_EXPR
&& (CONSTANT_CLASS_P (TREE_OPERAND (t, 0))
|| decl_address_invariant_p (TREE_OPERAND (t, 0)))));
}
A POLY_INT_CST "base" is a bit odd, GIMPLE IL verification would also
reject this but it could trivially happen via constant propagation
from
_1 = POLY_INT_CST [16B, 16B];
MEM [_1 + ivtmp_97 * 8] = ...
as it does here indirectly, after jump threading:
LKUP STMT _57 = POLY_INT_CST [16B, 16B]
==== ASGN _57 = POLY_INT_CST [16B, 16B]
Optimizing statement MEM <vector([2,2]) double> [(double *)_57 + ivtmp_97 * 8]
= vect__26.60_90;
Replaced '_57' with constant 'POLY_INT_CST [16B, 16B]'
