https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
--- Comment #41 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rguent...@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.
