On Thu, 4 Sep 2014, Jakub Jelinek wrote: > On Thu, Sep 04, 2014 at 02:11:26PM +0200, Richard Biener wrote: > > Sofar I have only fully tested removing try_move_mult_to_index > > on trunk which has some fallout that I have fixed and some > > fallout that should be addressed as followup. The patch > > Doesn't that regress e.g. testcases where users would expect > such expressions to be folded in initializers, __builtin_constant_p and > similar? If only one case in fold_plusminus_mult_expr is problematic, > removing the whole function altogether sounds too risky to me.
Removing try_move_mult_to_index it is, called from &OP1 p+ OP2 -> &OP1[...] folding. It mostly handles variable-index arrays, but yes, in theory something previously constant might become non-constant. int a[4]; int i; const int *p = &a[i + 1] - i; is rejected by C before and after the patch, accepted by C++ (runtime initializer) and rejected with constexpr instead of const before and after the patch. Expressions without variable parts are handled by TREE_CONSTANT and the output machinery AFAIK. So my choice would be to leave fold_plusminus_mult_expr unmodified but remove try_move_mult_to_index and the &OP1 p+ OP2 -> &OP1[...] folding. Richard.
