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 <rguent...@suse.de> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)