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: [PATCH] c++: Fix up constexpr evaluation of new with zero sized types [PR104568]
Date: Mon, 21 Feb 2022 09:25:03 +0100	[thread overview]
Message-ID: <YhNMX3YSOSgt9epK@tucnak> (raw)

Hi!

The new expression constant expression evaluation right now tries to
deduce how many elts the array it uses for the heap or heap [] vars
should have (or how many elts should its trailing array have if it has
cookie at the start).  As new is lowered at that point to
(some_type *) ::operator new (size)
or so, it computes it by subtracting cookie size if any from size, then
divides the result by sizeof (some_type).
This works fine for most types, except when sizeof (some_type) is 0,
then we divide by zero; size is then equal to cookie_size (or if there
is no cookie, to 0).
The following patch special cases those cases so that we don't divide
by zero and also recover the original outer_nelts from the expression
by forcing the size not to be folded in that case but be explicit
0 * outer_nelts or cookie_size + 0 * outer_nelts.

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

Note, we have further issues, we accept-invalid various cases, for both
zero sized elt_type and even non-zero sized elts, we aren't able to
diagnose out of bounds POINTER_PLUS_EXPR like:
constexpr bool
foo ()
{
  auto p = new int[2];
  auto q1 = &p[0];
  auto q2 = &p[1];
  auto q3 = &p[2];
  auto q4 = &p[3];
  delete[] p;
  return true;
}
constexpr bool a = foo ();
That doesn't look like a regression so I think we should resolve that for
GCC 13, but there are 2 problems.  Figure out why
cxx_fold_pointer_plus_expression doesn't deal with the &heap []
etc. cases, and for the zero sized arrays, I think we really need to preserve
whether user wrote an array ref or pointer addition, because in the
&p[3] case if sizeof(p[0]) == 0 we know that if it has 2 elements it is
out of bounds, while if we see p p+ 0 the information if it was
p + 2 or p + 3 in the source is lost.
clang++ seems to handle it fine even in the zero sized cases or with
new expressions.

2022-02-21  Jakub Jelinek  <jakub@redhat.com>

	PR c++/104568
	* cp-tree.h (build_new_constexpr_heap_type): Add FULL_SIZE_ADJUSTED
	argument.
	* init.cc (build_new_constexpr_heap_type): Add FULL_SIZE_ADJUSTED
	argument.  If true, don't subtract csz from it nor divide by
	int_size_in_bytes (elt_type).  Don't do that division if
	int_size_in_bytes is zero either.
	(maybe_wrap_new_for_constexpr): Pass false to
	build_new_constexpr_heap_type.
	(build_new_1): If size is 0, change it to 0 * outer_nelts if
	outer_nelts is non-NULL.  Pass type rather than elt_type to
	maybe_wrap_new_for_constexpr.
	* constexpr.cc (cxx_eval_constant_expression) <case CONVERT_EXPR>:
	If elt_size is zero sized type, try to recover outer_nelts from
	the size argument to operator new/new[] and pass that as
	var_size to build_new_constexpr_heap_type together with true
	for the last argument.

	* g++.dg/cpp2a/constexpr-new22.C: New test.

--- gcc/cp/cp-tree.h.jj	2022-02-09 20:13:51.541304861 +0100
+++ gcc/cp/cp-tree.h	2022-02-17 15:34:30.804453673 +0100
@@ -7038,7 +7038,7 @@ extern tree build_offset_ref			(tree, tr
 extern tree throw_bad_array_new_length		(void);
 extern bool type_has_new_extended_alignment	(tree);
 extern unsigned malloc_alignment		(void);
-extern tree build_new_constexpr_heap_type	(tree, tree, tree);
+extern tree build_new_constexpr_heap_type	(tree, tree, tree, bool);
 extern tree build_new				(location_t,
 						 vec<tree, va_gc> **, tree,
 						 tree, vec<tree, va_gc> **,
--- gcc/cp/init.cc.jj	2022-02-05 10:50:05.000000000 +0100
+++ gcc/cp/init.cc	2022-02-17 15:56:30.010056499 +0100
@@ -2930,7 +2930,8 @@ std_placement_new_fn_p (tree alloc_fn)
    it is computed such that the size of the struct fits into FULL_SIZE.  */
 
 tree
-build_new_constexpr_heap_type (tree elt_type, tree cookie_size, tree full_size)
+build_new_constexpr_heap_type (tree elt_type, tree cookie_size, tree full_size,
+			       bool full_size_adjusted)
 {
   gcc_assert (cookie_size == NULL_TREE || tree_fits_uhwi_p (cookie_size));
   gcc_assert (full_size == NULL_TREE || tree_fits_uhwi_p (full_size));
@@ -2939,9 +2940,14 @@ build_new_constexpr_heap_type (tree elt_
   if (full_size)
     {
       unsigned HOST_WIDE_INT fsz = tree_to_uhwi (full_size);
-      gcc_assert (fsz >= csz);
-      fsz -= csz;
-      fsz /= int_size_in_bytes (elt_type);
+      unsigned HOST_WIDE_INT esz = int_size_in_bytes (elt_type);
+      if (!full_size_adjusted)
+	{
+	  gcc_assert (fsz >= csz);
+	  fsz -= csz;
+	  if (esz)
+	    fsz /= esz;
+	}
       itype2 = build_index_type (size_int (fsz - 1));
       if (!cookie_size)
 	return build_cplus_array_type (elt_type, itype2);
@@ -2992,7 +2998,7 @@ maybe_wrap_new_for_constexpr (tree alloc
     return alloc_call;
 
   tree rtype = build_new_constexpr_heap_type (elt_type, cookie_size,
-					      NULL_TREE);
+					      NULL_TREE, false);
   return build_nop (build_pointer_type (rtype), alloc_call);
 }
 
@@ -3398,6 +3404,12 @@ build_new_1 (vec<tree, va_gc> **placemen
 	    outer_nelts_check = NULL_TREE;
 	}
 
+      /* If size is zero e.g. due to type having zero size, try to
+	 preserve outer_nelts for constant expression evaluation
+	 purposes.  */
+      if (integer_zerop (size) && outer_nelts)
+	size = build2 (MULT_EXPR, TREE_TYPE (size), size, outer_nelts);
+
       alloc_call = build_operator_new_call (fnname, placement,
 					    &size, &cookie_size,
 					    align_arg, outer_nelts_check,
@@ -3474,7 +3486,7 @@ build_new_1 (vec<tree, va_gc> **placemen
     }
 
   if (cookie_size)
-    alloc_call = maybe_wrap_new_for_constexpr (alloc_call, elt_type,
+    alloc_call = maybe_wrap_new_for_constexpr (alloc_call, type,
 					       cookie_size);
 
   /* In the simple case, we can stop now.  */
--- gcc/cp/constexpr.cc.jj	2022-02-17 10:24:16.779112954 +0100
+++ gcc/cp/constexpr.cc	2022-02-17 15:43:23.399026306 +0100
@@ -7253,6 +7253,7 @@ cxx_eval_constant_expression (const cons
 	    tree var_size = TYPE_SIZE_UNIT (TREE_TYPE (var));
 	    tree elt_type = TREE_TYPE (type);
 	    tree cookie_size = NULL_TREE;
+	    bool var_size_adjusted = false;
 	    if (TREE_CODE (elt_type) == RECORD_TYPE
 		&& TYPE_NAME (elt_type) == heap_identifier)
 	      {
@@ -7264,9 +7265,66 @@ cxx_eval_constant_expression (const cons
 	    DECL_NAME (var)
 	      = (DECL_NAME (var) == heap_uninit_identifier
 		 ? heap_identifier : heap_vec_identifier);
+	    /* For zero sized elt_type, try to recover how many outer_nelts
+	       it should have.  */
+	    if ((cookie_size ? tree_int_cst_equal (var_size, cookie_size)
+			     : integer_zerop (var_size))
+		&& !int_size_in_bytes (elt_type)
+		&& TREE_CODE (oldop) == CALL_EXPR
+		&& call_expr_nargs (oldop) >= 1)
+	      if (tree fun = get_function_named_in_call (oldop))
+		if (cxx_replaceable_global_alloc_fn (fun)
+		    && IDENTIFIER_NEW_OP_P (DECL_NAME (fun)))
+		  {
+		    tree arg0 = CALL_EXPR_ARG (oldop, 0);
+		    STRIP_NOPS (arg0);
+		    if (cookie_size)
+		      {
+			if (TREE_CODE (arg0) != PLUS_EXPR)
+			  arg0 = NULL_TREE;
+			else if (TREE_CODE (TREE_OPERAND (arg0, 0))
+				 == INTEGER_CST
+				 && tree_int_cst_equal (cookie_size,
+							TREE_OPERAND (arg0,
+								      0)))
+			  {
+			    arg0 = TREE_OPERAND (arg0, 1);
+			    STRIP_NOPS (arg0);
+			  }
+			else if (TREE_CODE (TREE_OPERAND (arg0, 1))
+				 == INTEGER_CST
+				 && tree_int_cst_equal (cookie_size,
+							TREE_OPERAND (arg0,
+								      1)))
+			  {
+			    arg0 = TREE_OPERAND (arg0, 0);
+			    STRIP_NOPS (arg0);
+			  }
+			else
+			  arg0 = NULL_TREE;
+		      }
+		    if (arg0 && TREE_CODE (arg0) == MULT_EXPR)
+		      {
+			tree op0 = TREE_OPERAND (arg0, 0);
+			tree op1 = TREE_OPERAND (arg0, 1);
+			var_size_adjusted = true;
+			if (integer_zerop (op0))
+			  var_size
+			    = cxx_eval_constant_expression (ctx, op1, false,
+							    non_constant_p,
+							    overflow_p);
+			else if (integer_zerop (op1))
+			  var_size
+			    = cxx_eval_constant_expression (ctx, op0, false,
+							    non_constant_p,
+							    overflow_p);
+			else
+			  var_size_adjusted = false;
+		      }
+		  }
 	    TREE_TYPE (var)
 	      = build_new_constexpr_heap_type (elt_type, cookie_size,
-					       var_size);
+					       var_size, var_size_adjusted);
 	    TREE_TYPE (TREE_OPERAND (op, 0))
 	      = build_pointer_type (TREE_TYPE (var));
 	  }
--- gcc/testsuite/g++.dg/cpp2a/constexpr-new22.C.jj	2022-02-17 16:01:24.804945381 +0100
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-new22.C	2022-02-17 16:00:55.720350985 +0100
@@ -0,0 +1,42 @@
+// PR c++/104568
+// { dg-do compile { target c++20 } }
+// { dg-options "" }
+
+struct S { int s; constexpr S () : s (0) {} constexpr ~S () {} };
+typedef int T[0];
+typedef int U[0];
+
+constexpr bool
+foo ()
+{
+  auto p = new T[2];
+  auto q1 = &p[0];
+  auto q2 = &p[1];
+  auto q3 = &p[2];
+  delete[] p;
+  return true;
+}
+
+constexpr bool
+bar ()
+{
+  auto p = new U[2];
+  auto q1 = &p[0];
+  auto q2 = &p[1];
+  auto q3 = &p[2];
+  delete[] p;
+  return true;
+}
+
+constexpr bool
+baz ()
+{
+  auto p = new T[0];
+  auto q1 = &p[0];
+  delete[] p;
+  return true;
+}
+
+constexpr bool a = foo ();
+constexpr bool b = bar ();
+constexpr bool c = baz ();

	Jakub


             reply	other threads:[~2022-02-21  8:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21  8:25 Jakub Jelinek [this message]
2022-03-12  4:28 ` Jason Merrill
2022-03-15 11:44   ` Jakub Jelinek
2022-03-15 20:19     ` Jason Merrill
2022-03-16 16:55       ` [PATCH] c++, v2: " Jakub Jelinek
2022-03-18 16:46         ` 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=YhNMX3YSOSgt9epK@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).