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: [PATCH] c++: Fix up constexpr evaluation of new with zero sized types [PR104568]
Date: Tue, 15 Mar 2022 12:44:09 +0100	[thread overview]
Message-ID: <YjB8CSo6lkyJV3ks@tucnak> (raw)
In-Reply-To: <5d0d1a93-c4af-b728-913a-5f70a6d9faed@redhat.com>

On Fri, Mar 11, 2022 at 11:28:09PM -0500, Jason Merrill wrote:
> > @@ -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);
> 
> How about setting var_size to arg0 at this point, and moving the
> decomposition of the size expression into build_new_constexpr_heap_type?

That would be more difficult, because for the cxx_eval_constant_expression
calls we need ctx, non_constant_p and overflow_p arguments, so
build_new_constexpr_heap_type would need to remove that one bool arg
added by this patch but instead pass around those 3 new ones.
As build_new_constexpr_heap_type is called only from 2 spots where the
other one passes NULL as full_size, the decomposition is only useful
for this caller and not the other one.

But if you strongly prefer it that way, I can do that.
Note, probably not 3 new args but 4, depends on whether we could turn
all those cases where the tree arg0 = CALL_EXPR_ARG (oldop, 0);
is done but var_size_adjusted is false into assertion failures.
I'm worried that with the zero size of element we could end up with
a variable number of elements which when multiplied by 0 gives constant 0,
though hopefully that would be rejected earlier during constant evaluation.
> 
> > +		    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));
> >   	  }

	Jakub


  reply	other threads:[~2022-03-15 11:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21  8:25 Jakub Jelinek
2022-03-12  4:28 ` Jason Merrill
2022-03-15 11:44   ` Jakub Jelinek [this message]
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=YjB8CSo6lkyJV3ks@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).