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: Joseph Myers <joseph at codesourcery dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Wed, 13 May 2015 15:06:00 +0000
- 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> <20150513141115 dot GC27320 at redhat dot com>
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).
I think this illustrates why handling this in the folding-for-optimization
is a mistake.
For optimization, it's perfectly fine to fold away 0 * (something without
side effects), and division by 0 should only be considered to have side
effects if language semantic options were specified to that effect (such
as using ubsan), which should then have the effect of producing GENERIC
that's not a simple division but represents whatever checks are required.
Rather, how about having an extra argument to c_fully_fold_internal (e.g.
for_int_const) indicating that the folding is of an expression with
integer constant operands (so this argument would be true in the new case
of folding the contents of a C_MAYBE_CONST_EXPR with
C_MAYBE_CONST_EXPR_INT_OPERANDS set)? In that special case,
c_fully_fold_internal would only fold the expression itself if all
evaluated operands folded to INTEGER_CSTs (so if something that doesn't
get folded, such as division by 0, is encountered, then all evaluated
expressions containing it also don't get folded).
--
Joseph S. Myers
joseph@codesourcery.com