https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97405
--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > OK, looks like the code expects > > POLY_INT_CST [16, 16] /[ex] 16 > > to be constant folded - looks like poly_int_binop doesn't handle division > nor is there a wi::div_trunc for poly_wide_int. > > This is generated here: > > Breakpoint 5, copy_reference_ops_from_ref (ref=<array_ref 0x7ffff642fa10>, > 891 /* But record element size in units of the type > alignment. */ > 892 temp.op2 = TREE_OPERAND (ref, 3); > 893 temp.align = eltype->type_common.align; > 894 if (! temp.op2) > 895 temp.op2 = size_binop (EXACT_DIV_EXPR, TYPE_SIZE_UNIT > (eltype), > 896 size_int (TYPE_ALIGN_UNIT > (eltype))); > > Hmm, I see that temp.op2 is indeed always needed unless we want to disrupt > valueization. copy_reference_ops_from_ref also isn't really allowed to fail. > > So we absolutely need to be able to fold this EXACT/TRUNC_DIV_EXPR. > > Richard? Yeah, EXACT_DIV_EXPR can't in general be folded at compile time because it wraps differently. We could perhaps fold it if TYPE_OVERFLOW_UNDEFINED is true, but by the letter of the law, we should issue a warning when doing that. I guess we want something similar to bd8a2482569900a114d631f9c38353d3a96a1d85 (And it would be nice if we didn't have too many copies of this code. ;-))
