This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix pattern causing C_MAYBE_CONST_EXPRs leak into gimplifier (PR c/68513)
- From: Richard Biener <rguenther at suse dot de>
- 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>
- Date: Thu, 26 Nov 2015 19:15:04 +0100
- Subject: Re: [PATCH] Fix pattern causing C_MAYBE_CONST_EXPRs leak into gimplifier (PR c/68513)
- Authentication-results: sourceware.org; auth=none
- References: <20151125143509 dot GU21807 at redhat dot com> <20151125144620 dot GY5675 at tucnak dot redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511251508280 dot 22015 at digraph dot polyomino dot org dot uk> <20151126111547 dot GX21807 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511261220050 dot 19588 at digraph dot polyomino dot org dot uk> <20151126161026 dot GY21807 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511261623030 dot 10502 at digraph dot polyomino dot org dot uk>
On November 26, 2015 5:36:34 PM GMT+01:00, Joseph Myers <joseph@codesourcery.com> wrote:
>On Thu, 26 Nov 2015, Marek Polacek wrote:
>
>> My worry was of course C_MAYBE_CONST_EXPR_PRE. But it seems we'll
>never have
>> any at that point, since it's already been processed and transformed
>to a
>> COMPOUND_EXPR. But do I like this patch? No.
>
>It's not obvious to me that it will always have been transformed - if a
>
>C_MAYBE_CONST_EXPR has escaped to gimplification, why shouldn't it be
>one
>with C_MAYBE_CONST_EXPR_PRE?
>
>Also, on further consideration: the folding via c_fully_fold is relied
>upon to get information about whether an expression contains anything
>that
>cannot occur in an evaluated part of a constant expression / outside
>sizeof in a constant expression in C90 mode. So if a SAVE_EXPR is
>created
>by language-independent code, c_fully_fold doesn't see inside it and
>you
>lose that information. What that says to me is that maybe a better
>interim solution would be a lang hook for the folders to use to call
>c_save_expr instead of save_expr. And then longer term: (a) maybe any
>folding that involves duplicating expressions and so needs to create
>SAVE_EXPRs would better be done only at the GIMPLE level, and (b)
>folding
>for conversions should be delayed as much as possible like other
>folding
>(and optimizations of conversions should move from convert.c to
>match.pd).
It would be easy to simply never generate any save_exprs from genmatch generated code with the effect of disabling foldings that would need it (for correctness).
Richard.