[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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)?