https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111151
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Richard Biener from comment #5) > but even when overflow is undefined we don't know whether we introduce > additional overflow then. Consider MAX (INT_MIN, 0) * -1 where we compute > 0 * -1 (fine) but after the transform we'd do MIN (INT_MIN * -1, 0) > which isn't valid. > > And when overflow wraps consider MAX (UINT_MAX, 1) * 2 which > will compute UINT_MAX * 2 == 0 while MAX (UINT_MAX * 2, 1 * 2) will compute > 2. > > Unless I'm missing something. You're right. So perhaps punt on this optimization for code == MULT_EXPR altogether. For the division/modulo, the problematic case is signed division by -1 (unless we can prove that neither operand is signed type minimum), but c is constant here, so we could as well just punt for code == MULT_EXPR || integer_minus_onep (c)?
