On May 14, 2015 12:46:06 AM GMT+02:00, Joseph Myers <jos...@codesourcery.com>
wrote:
>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.
Do the patches allow us to remove the restrictions from the folding patterns?
Richard.
