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

[Joseph Myers]

On Wed, 13 May 2015, Marek Polacek wrote:

> > 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).
> 
> Did you mean something like the following?  It is on top of the previous
> c_fully_fold_internal patch; if it makes any sense, I'll squash these
> into one.

Yes.  The two patches are OK together, though I think it would be better 
to add for_int_const checks also in the cases of unary operations, &&, || 
and ?: (the last three being cases where it's only the evaluated operands 
that need to fold to INTEGER_CSTs, not any unevaluated operands).  It may 
well be the case that no folding at present can fold any of those cases to 
an INTEGER_CST when it shouldn't be one, but I don't think we should rely 
on that.

> This still doesn't reject enum { A = 0 * (unsigned) (1 / 0) };, but note
> that we don't reject such an enum at present.

It's rejected with -pedantic-errors, but it should indeed be rejected 
unconditionally like the other cases.

Casts can do some optimization prematurely, but I don't know if that has 
anything to do with the non-rejection here.

-- 
Joseph S. Myers
joseph@codesourcery.com