[PATCH] c++: partial ordering with memfn pointer cst [PR108104]

[PATCH] c++: partial ordering with memfn pointer cst [PR108104]

[Patrick Palka]

Here we're triggering an overzealous assert in unify during partial
ordering since the member function pointer constants are represented as
ordinary CONSTRUCTORs (with TYPE_PTRMEMFUNC_P TREE_TYPE) but the assert
expects only COMPOUND_LITERAL_P constructors.

Bootstrapped and regtested on x86_64-pc-linux, does this look OK for
trunk and perhaps 12?

	PR c++/108104

gcc/cp/ChangeLog:

	* pt.cc (unify) <default>: Relax assert to accept any
	CONSTRUCTOR not just COMPOUND_LITERAL_P ones.

gcc/testsuite/ChangeLog:

	* g++.dg/template/ptrmem33.C: New test.
---
 gcc/cp/pt.cc                             |  2 +-
 gcc/testsuite/g++.dg/template/ptrmem33.C | 30 ++++++++++++++++++++++++
 2 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/template/ptrmem33.C

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 2f0f7a39698..44058d30799 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -24921,7 +24921,7 @@ unify (tree tparms, tree targs, tree parm, tree arg, int strict,
       if (is_overloaded_fn (parm) || type_unknown_p (parm))
 	return unify_success (explain_p);
       gcc_assert (EXPR_P (parm)
-		  || COMPOUND_LITERAL_P (parm)
+		  || TREE_CODE (parm) == CONSTRUCTOR
 		  || TREE_CODE (parm) == TRAIT_EXPR);
     expr:
       /* We must be looking at an expression.  This can happen with
diff --git a/gcc/testsuite/g++.dg/template/ptrmem33.C b/gcc/testsuite/g++.dg/template/ptrmem33.C
new file mode 100644
index 00000000000..dca741ae5e2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/ptrmem33.C
@@ -0,0 +1,30 @@
+// PR c++/108104
+// { dg-do compile { target c++11 } }
+
+struct A {
+  void x();
+  void y();
+};
+
+enum State { On };
+
+template<State state, void (A::*)()>
+struct B {
+  static void f();
+};
+
+template<State state>
+struct B<state, nullptr> {
+  static void g();
+};
+
+template<State state>
+struct B<state, &A::y> {
+  static void h();
+};
+
+int main() {
+  B<State::On, &A::x>::f();
+  B<State::On, nullptr>::g();
+  B<State::On, &A::y>::h();
+}
-- 
2.39.0.56.g57e2c6ebbe

Re: [PATCH] c++: partial ordering with memfn pointer cst [PR108104]

[Jason Merrill]

On 12/14/22 19:01, Patrick Palka wrote:
> Here we're triggering an overzealous assert in unify during partial
> ordering since the member function pointer constants are represented as
> ordinary CONSTRUCTORs (with TYPE_PTRMEMFUNC_P TREE_TYPE) but the assert
> expects only COMPOUND_LITERAL_P constructors.
> 
> Bootstrapped and regtested on x86_64-pc-linux, does this look OK for
> trunk and perhaps 12?

OK for both.

> 	PR c++/108104
> 
> gcc/cp/ChangeLog:
> 
> 	* pt.cc (unify) <default>: Relax assert to accept any
> 	CONSTRUCTOR not just COMPOUND_LITERAL_P ones.
> 
> gcc/testsuite/ChangeLog:
> 
> 	* g++.dg/template/ptrmem33.C: New test.
> ---
>   gcc/cp/pt.cc                             |  2 +-
>   gcc/testsuite/g++.dg/template/ptrmem33.C | 30 ++++++++++++++++++++++++
>   2 files changed, 31 insertions(+), 1 deletion(-)
>   create mode 100644 gcc/testsuite/g++.dg/template/ptrmem33.C
> 
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 2f0f7a39698..44058d30799 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -24921,7 +24921,7 @@ unify (tree tparms, tree targs, tree parm, tree arg, int strict,
>         if (is_overloaded_fn (parm) || type_unknown_p (parm))
>   	return unify_success (explain_p);
>         gcc_assert (EXPR_P (parm)
> -		  || COMPOUND_LITERAL_P (parm)
> +		  || TREE_CODE (parm) == CONSTRUCTOR
>   		  || TREE_CODE (parm) == TRAIT_EXPR);
>       expr:
>         /* We must be looking at an expression.  This can happen with
> diff --git a/gcc/testsuite/g++.dg/template/ptrmem33.C b/gcc/testsuite/g++.dg/template/ptrmem33.C
> new file mode 100644
> index 00000000000..dca741ae5e2
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/ptrmem33.C
> @@ -0,0 +1,30 @@
> +// PR c++/108104
> +// { dg-do compile { target c++11 } }
> +
> +struct A {
> +  void x();
> +  void y();
> +};
> +
> +enum State { On };
> +
> +template<State state, void (A::*)()>
> +struct B {
> +  static void f();
> +};
> +
> +template<State state>
> +struct B<state, nullptr> {
> +  static void g();
> +};
> +
> +template<State state>
> +struct B<state, &A::y> {
> +  static void h();
> +};
> +
> +int main() {
> +  B<State::On, &A::x>::f();
> +  B<State::On, nullptr>::g();
> +  B<State::On, &A::y>::h();
> +}