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: Richard Biener <richard dot guenther at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>,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: Thu, 14 May 2015 09:59:49 +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> <20150513141115 dot GC27320 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1505131456470 dot 30846 at digraph dot polyomino dot org dot uk> <20150513191803 dot GG27320 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1505132240340 dot 29221 at digraph dot polyomino dot org dot uk>
On May 14, 2015 12:46:06 AM GMT+02:00, Joseph Myers <joseph@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.