https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Those correctly say that division by zero may trap. That doesn't tell that
division by zero is not undefined behavior, but well defined to trap.
This new optimization, or e.g. operator_div::wi_fold's
// If we're definitely dividing by zero, there's nothing to do.
if (wi_zero_p (type, divisor_min, divisor_max))
{
r.set_undefined ();
return;
}
but even that
// Perform the division in 2 parts, [LB, -1] and [1, UB], which will
// skip any division by zero.
following it, I'm afraid a few further spots in match.pd, e.g.
/* X / bool_range_Y is X. */
(simplify
(div @0 SSA_NAME@1)
(if (INTEGRAL_TYPE_P (type) && ssa_name_has_boolean_range (@1))
@0))
or
/* X / X is one. */
(simplify
(div @0 @0)
/* But not for 0 / 0 so that we can get the proper warnings and errors.
And not for _Fract types where we can't build 1. */
(if (!integer_zerop (@0) && !ALL_FRACT_MODE_P (TYPE_MODE (type)))
{ build_one_cst (type); }))
/* X / abs (X) is X < 0 ? -1 : 1. */
(simplify
(div:C @0 (abs @0))
(if (INTEGRAL_TYPE_P (type)
&& TYPE_OVERFLOW_UNDEFINED (type))
(cond (lt @0 { build_zero_cst (type); })
{ build_minus_one_cst (type); } { build_one_cst (type); })))
/* X / -X is -1. */
(simplify
(div:C @0 (negate @0))
(if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
&& TYPE_OVERFLOW_UNDEFINED (type))
{ build_minus_one_cst (type); })))
etc.
I'm afraid it is all over the middle-end.
