Hello,
On Thu, 3 Feb 2022, Richard Biener via Gcc-patches wrote:
> /* Preserve explicit divisions by 0: the C++ front-end wants to detect
> undefined behavior in constexpr evaluation, and assuming that the
> division
> traps enables better optimizations than these anyway. */
> (for div (trunc_div ceil_div floor_div round_div exact_div)
> /* 0 / X is always zero. */
> (simplify
> (div integer_zerop@0 @1)
> /* But not for 0 / 0 so that we can get the proper warnings and errors.
> */
> (if (!integer_zerop (@1))
> @0))
>
> it suggests we want to preserve all X / 0 when the 0 is literal but
> I think we can go a bit further and require 0/0 to not unnecessarily
> restrict other special cases.
Just remember that 0/0 is completely different from X/0 (with X != 0), the
latter is a sensible limit, the former is just non-sense. There's a
reason why one is a NaN and the other Inf in floating point. So it does
make sense to differ between both on integer side as well.
(i'm split mind on the usefullness of "1/x -> 0" vs. its effect on
trapping behaviour)
Ciao,
Michael.
>
> Comments on the libgcc case below
>
> > 2022-02-03 Jakub Jelinek <ja...@redhat.com>
> >
> > * libgcc2.c (__udivmoddi4): Add optimization barriers to actually
> > ensure division by zero.
> >
> > --- libgcc/libgcc2.c.jj 2022-01-11 23:11:23.810270199 +0100
> > +++ libgcc/libgcc2.c 2022-02-03 09:24:14.513682731 +0100
> > @@ -1022,8 +1022,13 @@ __udivmoddi4 (UDWtype n, UDWtype d, UDWt
> > {
> > /* qq = NN / 0d */
> >
> > - if (d0 == 0)
> > - d0 = 1 / d0; /* Divide intentionally by zero. */
> > + if (__builtin_expect (d0 == 0, 0))
> > + {
> > + UWtype one = 1;
> > + __asm ("" : "+g" (one));
> > + __asm ("" : "+g" (d0));
> > + d0 = one / d0; /* Divide intentionally by zero. */
> > + }
>
> I'm not sure why we even bother - division or modulo by zero is
> undefined behavior and we are not emulating CPU behavior because
> the wide instructions emulated here do not actually exist. That
> gives us the freedom of choosing the implementation defined
> behavior.
>
> That said, _if_ we choose to "care" I'd rather choose to
> define the implementation to use the trap mechanism the
> target provides and thus use __builtin_trap (). That then
> at least traps reliably, compared to the division by zero
> which doesn't do that on all targets.
>
> So I'm not sure there's anything to fix besides eventually
> just deleting the d0 == 0 special case?
>
> Richard.
>
