This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
- From: Marek Polacek <polacek at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>, Joseph Myers <joseph at codesourcery dot com>
- Date: Wed, 13 May 2015 16:11:15 +0200
- Subject: Re: [PATCH] Don't fold away division by zero (PR middle-end/66127)
- Authentication-results: sourceware.org; auth=none
- References: <20150513134111 dot GA27320 at redhat dot com> <20150513135509 dot GE1751 at tucnak dot redhat dot com>
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>...
Marek