[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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #3)
> @@ -6970,8 +6972,11 @@ extract_muldiv_1 (tree t, tree c, enum tree_code
> code, tree wide_type,
>  
>        /* MIN (a, b) / 5 -> MIN (a / 5, b / 5)  */
>        sub_strict_overflow_p = false;
> -      if ((t1 = extract_muldiv (op0, c, code, wide_type,
> -                               &sub_strict_overflow_p)) != 0
> +      if ((wide_type
> +          ? TYPE_OVERFLOW_UNDEFINED (wide_type)
> +          : TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (op0))) 
> +         && (t1 = extract_muldiv (op0, c, code, wide_type,
> +                                  &sub_strict_overflow_p)) != 0
>           && (t2 = extract_muldiv (op1, c, code, wide_type,
>                                    &sub_strict_overflow_p)) != 0)
>         {

Isn't it fine as is for unsigned divisions and modulos?
I'd think the only problem is TYPE_OVERFLOW_WRAPS code == MULT_EXPR or
!TYPE_UNSIGNED && TYPE_OVERFLOW_WRAPS division/modulo (say -fwrapv MIN (a, b) /
-1
-> MAX (a / -1, b / -1) transformation wouldn't be correct for a INT_MIN b 0,
because the first one is INT_MIN / -1 aka. INT_MIN, while the latter is 0
or perhaps TYPE_OVERFLOW_SANITIZED should be punted on as well.