[Bug tree-optimization/104356] [12 Regression] divide by zero trap incorrectly optimized away

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356

--- Comment #41 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #40)
> On Thu, 3 Feb 2022, amacleod at redhat dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
> > 
> > --- Comment #37 from Andrew Macleod <amacleod at redhat dot com> ---
> > (In reply to Jakub Jelinek from comment #35)
> > > I meant something like:
> > >   return Z / X;
> > 
> > > and there evrp does with -O2 -gnatp optimize away the division.
> > > Though that is likely the X / boolean_range_Y case which you've disabled.
> > > In any case, I think you want to hear from Andrew/Aldy where exactly does
> > > VRP/ranger assume UB on integer division by zero.
> > 
> > That divide is remove by the simplifier because it determines that X has a
> > range of [0,1] and I believe the simplifer chooses to ignore the 0 under
> > various circumstances.
> > 
> > As for ranger, range-ops will return UNDEFINED for the range if x is known to
> > be [0,0].  This can be propagated around, and depending on how it ends up being
> > used as to what happens with it. 
> 
> I think that's OK as outgoing range (on the non-exceptional path - on the
> exeptional path the result isn't computed).  That just may not be used
> to simplify the stmt producing the range itself of course.

That said, range-ops, from say

  [0,1] = [0,2] / y;

may _not_ reason that 'y' is not 0 when non-call EH.  That is, you need to be
careful on the reverse ops but I think not on the forward ops.