This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++ PATCH] Constexpr fold even some TREE_CONSTANT ctors (PR c++/87934)


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.

Note, it doesn't fix this PR, as store_init_value is called only after we
emit the error, so the constexpr.c patch is needed too.

--- gcc/cp/cp-tree.h.jj	2018-12-12 23:43:57.211129676 +0100
+++ gcc/cp/cp-tree.h	2018-12-19 00:12:59.795154220 +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/typeck2.c.jj	2018-12-01 00:25:09.340988953 +0100
+++ gcc/cp/typeck2.c	2018-12-19 00:14:19.306875071 +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);
--- gcc/cp/cp-gimplify.c.jj	2018-12-17 22:54:02.736416699 +0100
+++ gcc/cp/cp-gimplify.c	2018-12-19 00:12:05.862021875 +0100
@@ -2171,6 +2171,32 @@ cp_fully_fold (tree x)
   return cp_fold_rvalue (x);
 }
 
+/* Likewise, but also fold recursively.  */
+
+tree
+cp_fully_fold_init (tree x)
+{
+  if (processing_template_decl)
+    return x;
+  /* FIXME cp_fold ought to be a superset of maybe_constant_value so we don't
+     have to call both.  */
+  if (cxx_dialect >= cxx11)
+    {
+      x = maybe_constant_value (x);
+      /* Sometimes we are given a CONSTRUCTOR but the call above wraps it into
+	 a TARGET_EXPR; undo that here.  */
+      if (TREE_CODE (x) == TARGET_EXPR)
+	x = TARGET_EXPR_INITIAL (x);
+      else if (TREE_CODE (x) == VIEW_CONVERT_EXPR
+	       && TREE_CODE (TREE_OPERAND (x, 0)) == CONSTRUCTOR
+	       && TREE_TYPE (TREE_OPERAND (x, 0)) == TREE_TYPE (x))
+	x = TREE_OPERAND (x, 0);
+    }
+  hash_set<tree> pset;
+  cp_walk_tree (&x, cp_fold_r, &pset, NULL);
+  return cp_fold_rvalue (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


	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]