Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)

[Richard Biener <rguenther at suse dot de>]

On Wed, 13 May 2015, Marek Polacek wrote:

> On Wed, May 13, 2015 at 03:55:10PM +0200, Jakub Jelinek wrote:
> > On Wed, May 13, 2015 at 03:41:11PM +0200, Marek Polacek wrote:
> > > As discussed in the PR, match.pd happily folds 0 * whatever into 0.  That
> > > is undesirable from the C/C++ FE POV, since it can make us accept invalid
> > > initializers.
> > > 
> > > So fixed in match.pd -- I'd hope there's a better way to do this, but this
> > > seems to work.  There was some fallout, but nothing unexpected or surprising.
> > 
> > Will it handle cases 0 * (int) (1 / 0) etc., when perhaps the division by
> > zero isn't immediately the operand of mult, but somewhere deeper?
> 
> It won't handle e.g. 0 * (unsigned) (1 / 0).
> 
> > Also, can't the divisor be optimized into 0 only later on, so your code
> > would still see !integer_zerop there and fold into 0?
> > Perhaps the answer is that in both cases we'd have simplified those already
> > into a division by zero.
> 
> Yes, it's a dumb attempt.
> 
> I don't know how to reliably fix this :(.  We really want 
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66127#c1>...

Yeah, I think we can't reliably "avoid" folding away traps like this
so any attempt is useless (and we should simply not do this).

The only way I see is to make all expressions that might trap set
TREE_SIDE_EFFECTS on the expression, so we'd fold it to
a, 0.

Richard.
-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)