public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Patrick Palka <ppalka@redhat.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] c++: Fix ICE in tsubst_default_argument [PR92010]
Date: Thu, 26 Mar 2020 15:29:01 -0400	[thread overview]
Message-ID: <debc11d2-e1ab-2c82-d0a5-5d62ee43d511@redhat.com> (raw)
In-Reply-To: <20200323012105.3692086-1-ppalka@redhat.com>

On 3/22/20 9:21 PM, Patrick Palka wrote:
> This patch relaxes an assertion in tsubst_default_argument that exposes a latent
> bug in how we substitute an array type into a cv-qualified wildcard function
> parameter type.  Concretely, the latent bug is that given the function template
> 
>    template<typename T> void foo(const T t);
> 
> one would expect the type of foo<int[]> to be void(const int*), but we
> (seemingly prematurely) strip function parameter types of their top-level
> cv-qualifiers when building the function's TYPE_ARG_TYPES, and instead end up
> obtaining void(int*) as the type of foo<int[]> after substitution and decaying.
> 
> We still however correctly substitute into and decay the formal parameter type,
> obtaining const int* as the type of t after substitution.  But this then leads
> to us tripping over the assert in tsubst_default_argument that verifies the
> formal parameter type and the function type are consistent.
> 
> Assuming it's too late at this stage to fix the substitution bug, we can still
> relax the assertion like so.  Tested on x86_64-pc-linux-gnu, does this look OK?

This is core issues 1001/1322, which have not been resolved.  Clang does 
the substitution the way you suggest; EDG rejects the testcase because 
the two substitutions produce different results.  I think it would make 
sense to follow the EDG behavior until this issue is actually resolved.

> gcc/cp/ChangeLog:
> 
> 	PR c++/92010
> 	* pt.c (tsubst_default_argument): Relax assertion to permit
> 	disagreements between the function type and the parameter type
> 	about the cv-qualification of the pointed-to type.
> 
> gcc/testsuite/ChangeLog:
> 
> 	PR c++/92010
> 	* g++.dg/template/defarg22.C: New test.
> ---
>   gcc/cp/pt.c                              | 17 ++++++++++++++++-
>   gcc/testsuite/g++.dg/template/defarg22.C | 11 +++++++++++
>   2 files changed, 27 insertions(+), 1 deletion(-)
>   create mode 100644 gcc/testsuite/g++.dg/template/defarg22.C
> 
> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> index 9e1eb9416c9..923166276b8 100644
> --- a/gcc/cp/pt.c
> +++ b/gcc/cp/pt.c
> @@ -13337,7 +13337,22 @@ tsubst_default_argument (tree fn, int parmnum, tree type, tree arg,
>     if (parmtype == error_mark_node)
>       return error_mark_node;
>   
> -  gcc_assert (same_type_ignoring_top_level_qualifiers_p (type, parmtype));
> +  if (same_type_ignoring_top_level_qualifiers_p (type, parmtype))
> +    ;
> +  else if (POINTER_TYPE_P (type) && POINTER_TYPE_P (parmtype))
> +    {
> +      /* The function type and the parameter type can disagree about the
> +	 cv-qualification of the pointed-to type; see PR92010.  */
> +      gcc_assert (same_type_p (TREE_TYPE (type),
> +			       strip_top_quals (TREE_TYPE (parmtype))));
> +      /* Verify that this happens only when the dependent parameter type is a
> +	 cv-qualified wildcard type.  */
> +      tree pattern_parm = get_pattern_parm (parm, DECL_TI_TEMPLATE (fn));
> +      gcc_assert (WILDCARD_TYPE_P (TREE_TYPE (pattern_parm))
> +		  && cv_qualified_p (TREE_TYPE (pattern_parm)));
> +    }
> +  else
> +    gcc_unreachable ();
>   
>     tree *slot;
>     if (defarg_inst && (slot = defarg_inst->get (parm)))
> diff --git a/gcc/testsuite/g++.dg/template/defarg22.C b/gcc/testsuite/g++.dg/template/defarg22.C
> new file mode 100644
> index 00000000000..cf6261916d8
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/defarg22.C
> @@ -0,0 +1,11 @@
> +// PR c++/92010
> +// { dg-do compile }
> +
> +template <typename T>
> +void foo(const T t = 0)
> +{ }
> +
> +int main()
> +{
> +  foo<char[]>();
> +}
> 


  parent reply	other threads:[~2020-03-26 19:29 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23  1:21 Patrick Palka
2020-03-23  3:11 ` Patrick Palka
2020-03-26 19:29 ` Jason Merrill [this message]
2020-03-30 19:58   ` Patrick Palka
2020-03-30 20:15     ` Patrick Palka
2020-03-30 20:42     ` Jason Merrill
2020-03-30 22:46       ` Patrick Palka
2020-03-31 17:13         ` Jason Merrill
2020-03-31 19:50           ` Patrick Palka
2020-04-01 22:29             ` Jason Merrill
2020-04-01 22:37               ` Jason Merrill
2020-04-06 15:45                 ` Patrick Palka
2020-04-06 21:33                   ` Jason Merrill
2020-04-07 17:40                     ` Patrick Palka
2020-04-07 20:26                       ` Patrick Palka
2020-04-07 21:21                       ` Jason Merrill
2020-04-08 14:18                         ` Patrick Palka

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=debc11d2-e1ab-2c82-d0a5-5d62ee43d511@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ppalka@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).