public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Jason Merrill <jason@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [C++ PATCH] Constexpr fold even some TREE_CONSTANT ctors (PR c++/87934)
Date: Wed, 19 Dec 2018 23:14:00 -0000	[thread overview]
Message-ID: <20181219231410.GK23305@tucnak> (raw)
In-Reply-To: <89ec010c-1b82-47ff-fd46-7f87d20b53e9@redhat.com>

On Tue, Dec 18, 2018 at 10:27:56PM -0500, Jason Merrill wrote:
> On 12/18/18 6:19 PM, Jakub Jelinek wrote:
> > On Tue, Dec 18, 2018 at 05:40:03PM -0500, Jason Merrill wrote:
> > > On 12/18/18 3:45 PM, Jakub Jelinek wrote:
> > > > The following testcase FAILs, because parsing creates a TREE_CONSTANT
> > > > CONSTRUCTOR that contains CONST_DECL elts.  cp_fold_r can handle that,
> > > > but constexpr evaluation doesn't touch those CONSTRUCTORs.
> > > > 
> > > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> > > > trunk?
> > > 
> > > OK.  I also wonder if store_init_value should use cp_fold_r rather than just
> > > cp_fully_fold.
> > 
> > I've been thinking about that already when working on the PR88410 bug.
> > 
> > Do you mean something like following completely untested patch?
> > Perhaps I could add a helper inline so that there is no code repetition
> > between cp_fully_fold and this new function.
> 
> Something like that, yes.

The following does the job too (even the PR88410 ICE is gone with the
cp-gimplify.c change from that patch reverted) and is shorter.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-12-19  Jakub Jelinek  <jakub@redhat.com>

	* cp-tree.h (cp_fully_fold_init): Declare.
	* cp-gimplify.c (cp_fully_fold_init): New function.
	* typeck2.c (split_nonconstant_init, store_init_value): Use it
	instead of cp_fully_fold.

--- gcc/cp/cp-tree.h.jj	2018-12-19 09:09:28.251543416 +0100
+++ gcc/cp/cp-tree.h	2018-12-19 14:57:54.719812330 +0100
@@ -7542,6 +7542,7 @@ extern bool cxx_omp_privatize_by_referen
 extern bool cxx_omp_disregard_value_expr	(tree, bool);
 extern void cp_fold_function			(tree);
 extern tree cp_fully_fold			(tree);
+extern tree cp_fully_fold_init			(tree);
 extern void clear_fold_cache			(void);
 extern tree lookup_hotness_attribute		(tree);
 extern tree process_stmt_hotness_attribute	(tree);
--- gcc/cp/cp-gimplify.c.jj	2018-12-19 09:09:28.335542037 +0100
+++ gcc/cp/cp-gimplify.c	2018-12-19 15:00:28.214293053 +0100
@@ -2171,6 +2171,20 @@ cp_fully_fold (tree x)
   return cp_fold_rvalue (x);
 }
 
+/* Likewise, but also fold recursively, which cp_fully_fold doesn't perform
+   in some cases.  */
+
+tree
+cp_fully_fold_init (tree x)
+{
+  if (processing_template_decl)
+    return x;
+  x = cp_fully_fold (x);
+  hash_set<tree> pset;
+  cp_walk_tree (&x, cp_fold_r, &pset, NULL);
+  return x;
+}
+
 /* c-common interface to cp_fold.  If IN_INIT, this is in a static initializer
    and certain changes are made to the folding done.  Or should be (FIXME).  We
    never touch maybe_const, as it is only used for the C front-end
--- gcc/cp/typeck2.c.jj	2018-12-19 09:09:28.401540956 +0100
+++ gcc/cp/typeck2.c	2018-12-19 14:57:54.736812061 +0100
@@ -750,7 +750,7 @@ split_nonconstant_init (tree dest, tree
     init = TARGET_EXPR_INITIAL (init);
   if (TREE_CODE (init) == CONSTRUCTOR)
     {
-      init = cp_fully_fold (init);
+      init = cp_fully_fold_init (init);
       code = push_stmt_list ();
       if (split_nonconstant_init_1 (dest, init))
 	init = NULL_TREE;
@@ -858,7 +858,7 @@ store_init_value (tree decl, tree init,
       if (!const_init)
 	value = oldval;
     }
-  value = cp_fully_fold (value);
+  value = cp_fully_fold_init (value);
 
   /* Handle aggregate NSDMI in non-constant initializers, too.  */
   value = replace_placeholders (value, decl);


	Jakub

  reply	other threads:[~2018-12-19 23:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18 20:45 Jakub Jelinek
2018-12-18 22:40 ` Jason Merrill
2018-12-18 23:19   ` Jakub Jelinek
2018-12-19  3:28     ` Jason Merrill
2018-12-19 23:14       ` Jakub Jelinek [this message]
2018-12-20 16:01         ` Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181219231410.GK23305@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).