[Bug tree-optimization/104356] [12 Regression] divide by zero trap is being removed now when it should not be in some cases

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 3 Feb 2022, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
> 
> --- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > Of course integer division might be special enough to single out as IIRC
> > > all CPUs trap on that (I'm sure somebody knows one that does not...).
> > 
> > MIPS backend adds the trap (it can be turned off by a backend flag).
> > AARCH64 and PowerPC don't trap either.
> 
> The Java front-end used to have option which caused the front-end to emit the
> throw/trap for the division by zero which was turned off for a few targets (I
> can't remember if it was a hook or hard coded).

I suppose a set of [us]div_trap_on_zero patterns could be used to
merge a conditional trap with division during combine if we want to go
there.  But that suggests that if in Ada integer divide by zero is
something the language standard mandates special behavior for then
either the frontend (with help from the middle-end) or the
middle-end (by singling out integer division with -fnon-call-exceptions)
needs to make the operation well-defined - preferably in an explicit way.
These days we'd probably add IFN_TRUNC_DIV_OR_TRAP for this purpose.

I don't mind guarding the pattern for GCC 12 though, but I'd like
to clarify the semantic questions raised here.