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: Joseph Myers <joseph at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat 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:34:44 +0000
- 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> <20151126164210 dot GH5675 at tucnak dot redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511261704500 dot 10502 at digraph dot polyomino dot org dot uk> <20151126171019 dot GI5675 at tucnak dot redhat dot com>
On Thu, 26 Nov 2015, Jakub Jelinek wrote:
> > > 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?
> >
> > Yes, I think so.
>
> It seems only to be set temporarily when calling convert*, then reset
> back, while we supposedly want to use save_expr instead of c_save_expr also
> at the point where we are genericizing, or gimplifying etc.
OK, then we may need a new flag that indicates that we are doing some
processing after all the constant expression checks from parsing have been
done. (With an eventual preference that anything creating SAVE_EXPRs at
all should happen at that late stage - that the front-end representation
created during parsing should be closer to the source, including not
needing to refer more than once to a given source expression, and
genericizing / gimplifying / some such lowering step handling semantics
that require SAVE_EXPRs.)
--
Joseph S. Myers
joseph@codesourcery.com