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
jos...@codesourcery.com
