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: Jakub Jelinek <jakub at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Thu, 26 Nov 2015 17:42:10 +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>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Nov 26, 2015 at 04:36:34PM +0000, Joseph Myers 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
But the condition whether to call c_save_expr or whether to call save_expr
instead is not constant in the C FE.
If c_fully_fold is expected to be called on the expression, then c_save_expr
needs to be used, otherwise save_expr.
Can we rely on in_late_binary_op for that?
> 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).
Jakub