This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++/c-common PATCH for c++/68767 (warning regression with ?:)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 18 Jan 2016 17:06:31 +0100
- Subject: Re: C++/c-common PATCH for c++/68767 (warning regression with ?:)
- Authentication-results: sourceware.org; auth=none
- References: <569D0A85 dot 50501 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Jan 18, 2016 at 10:53:41AM -0500, Jason Merrill wrote:
> In this testcase, we weren't getting the benefits of fold's cleverness in
> handling COND_EXPR because we were only calling fold_for_warn on the
> condition itself. This patch changes check_function_arguments_recurse to
> fold the entire COND_EXPR, and also fixes cp_fold to actually fold
> COND_EXPR.
>
> Along with this, I've cleaned up some other bits I noticed in cp_fold: there
> was various unnecessary special-casing for unary and binary ops as well, and
> we were clobbering an input CONSTRUCTOR rather than returning a new folded
> one.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
Guess too late for GCC 6, but I'm slightly worried about fold_for_warn
compile time complexity, if we have very large trees of expressions and try
to fold_for_warn it all, then on the original fold_for_warn 2-3 operands
thereof and so on, with something foldable somewhere very deep in the trees.
For that perhaps best would be if we cache cp_fold results on
expressions somewhere (custom tree that holds original and corresponding
folded expression, or hash table, whatever) and if we try to cp_fold it
again, we just reuse what we've folded it to last time.
Jakub