https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111151
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #8) > (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. Although, even for MULT_EXPR when TYPE_OVERFLOW_UNDEFINED, if the only problematic cases are when one of the multiplication operand is -1 and the other is signed minimum, because we know one of those operands (c), we could just punt if integer_minus_onep (c) or if c is TYPE_MIN_VALUE.
