[gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jan Kratochvil]

On Wed, 22 Jun 2011 17:42:34 +0200, Jason Merrill wrote:
> Well, the basic issue is that the "linkage name" is produced by
> libiberty/cp-demangle.c and the DW_AT_name is produced by
> gcc/cp/error.c, and they don't always agree on the same
> pretty-printed representation of a C++ expression.

Filed cross-check RFE GCC PR debug/49537 for it.


> >The function linkage name has prefix: K<&(S::m(int))>
> 
> This isn't actually valid C++ syntax, so the demangler should be adjusted.

Attached.  No regressions on gcc-4.6.0-10.fc15.x86_64.  OK for check it in?

It fixes (and GDB commands start to work):
K<&(S::m(int))>::f (this=0x7fffffffdcaf) at tmplmember.C:6
->
K<&S::m>::f (this=0x7fffffffdcaf) at tmplmember.C:6
BTW the above change is when using DW_AT_linkage_name; FSF GDB HEAD still uses
physname computation but that is also not right:
K<&(S::m)>::f (this=0x7fffffffdcaf) at tmplmember.C:6
------------------------------------------------------------------------------
struct S {
  void m (int x) {}
};
template<void (S::*F) (int)>
struct K {
  void f () { S s; (s.*F) (5); }
};
int main () {
  K<&S::m> k;
  k.f ();
}
------------------------------------------------------------------------------

Filed as GCC PR debug/49546 that GDB still does not work (*) for:
(*) without implementing - filed as GDB PR c++/12936:
On Wed, 22 Jun 2011 17:42:34 +0200, Jason Merrill wrote:
# > Or maybe it is not a bug and one just has to accept the function prefix may
# > not match its struct/class name?
# This would also be a good idea, for robustness when this kind of
# issue crops up.
------------------------------------------------------------------------------
struct S {
  static void m (int x) {}
};
template<void (*T) (int)>
// or: template<void (T) (int)>
struct K {
  void f () { T (0); }
};
int main () {
  K<&S::m> k;
// or: K<S::m> k;
  k.f ();
}
------------------------------------------------------------------------------

DWARF is exactly the for all the four combination of alternative lines.
In the member function pointer above no alternative source form gets compiled.

As both K<&S::m>::f() functions have exactly the same mangled name
_ZN1KIXadL_ZN1S1mEiEEE1fEv , the demangled names should match the source form
and in the first example it is the only allowed form of the source the
function should demangled to K<&S::m>::f() - as it is by the patch below.
But in the second example the template instace `struct K' DW_AT_name is
K<S::m> so it cannot match the function K<&S::m>::f() prefix.

But in the second case it also cannot always match the source form when
multiple source notations compile into exactly the same output.

FYI:
_ZN1KIXadL_ZN1S1mEiEEE1fEv
typed name
  qualified name
    template
      name 'K'
      template argument list
        unary operator
          operator &
          typed name
            qualified name
              name 'S'
              name 'm'
            function type
              argument list
                builtin type int
    name 'f'
  function type
    argument list


For GDB this patch resolves a regression of combination:
	Re: [patch] Follow DW_AT_linkage_name for methods #2
	http://sourceware.org/ml/gdb-patches/2011-06/msg00040.html
and
	FYI: updates to temargs.exp
	http://sourceware.org/ml/gdb-patches/2011-06/msg00138.html


On Wed, 22 Jun 2011 21:55:47 +0200, Gabriel Dos Reis wrote:
> I agree this isn't valid C++ syntax.  However, it is a syntax used in certain
> popular frameworks, e.g. QT signal/slots, and it unambiguously tells in a
> readable manner what function is intended from overload resolution perspective.

There is now for some time for the template:
 <2><92>: Abbrev Number: 11 (DW_TAG_template_value_param)
    <93>   DW_AT_name        : F        
    <95>   DW_AT_type        : <0x16f>  

pointing (<0x16f>) to the member function so it is more up to the debugger (or
front-end) to show it.  Had to file GDB PR c++/12933 for it, though.


Had to restrict the patch very much for the template function reference case as
otherwise the parameter types are required even in templates there.


Thanks,
Jan


libiberty/
2011-06-27  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* cp-demangle.c (d_print_comp): Suppress argument list for function
	references as template arguments.
	* testsuite/demangle-expected: 3 new testcases for it.

--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -4095,7 +4095,56 @@ d_print_comp (struct d_print_info *dpi, int options,
     case DEMANGLE_COMPONENT_ARGLIST:
     case DEMANGLE_COMPONENT_TEMPLATE_ARGLIST:
       if (d_left (dc) != NULL)
-	d_print_comp (dpi, options, d_left (dc));
+	{
+	  const struct demangle_component *left = d_left (dc);
+
+	  if (dc->type == DEMANGLE_COMPONENT_TEMPLATE_ARGLIST
+	      && left->type == DEMANGLE_COMPONENT_UNARY
+	      && d_left (left)->type == DEMANGLE_COMPONENT_OPERATOR
+	      && d_left (left)->u.s_operator.op->len == 1
+	      && d_left (left)->u.s_operator.op->name[0] == '&'
+	      && d_right (left)->type == DEMANGLE_COMPONENT_TYPED_NAME
+	      && d_left (d_right (left))->type == DEMANGLE_COMPONENT_QUAL_NAME
+	      && d_right (d_right (left))->type == DEMANGLE_COMPONENT_FUNCTION_TYPE)
+	    {
+	      /* Address of a function in template argument list must have its
+		 argument list suppressed.  The resolution is already not
+		 ambiguous due to the function type expected by the template.
+
+		 template argument list
+		   unary operator ... left
+		     operator & ... d_left (left)
+		     typed name ... d_right (left)
+		       qualified name ... d_left (d_right (left))
+			 <names>
+		       function type ... d_right (d_right (left))
+			 argument list
+			   <arguments>  */
+
+	      d_print_expr_op (dpi, options, d_left (left));
+	      d_print_comp (dpi, options, d_left (d_right (left)));
+	    }
+	  else if (dc->type == DEMANGLE_COMPONENT_TEMPLATE_ARGLIST
+	      && left->type == DEMANGLE_COMPONENT_UNARY
+	      && d_left (left)->type == DEMANGLE_COMPONENT_OPERATOR
+	      && d_left (left)->u.s_operator.op->len == 1
+	      && d_left (left)->u.s_operator.op->name[0] == '&'
+	      && d_right (left)->type == DEMANGLE_COMPONENT_QUAL_NAME)
+	    {
+	      /* Keep also already processed variant without the argument list.
+
+		 template argument list
+		   unary operator ... left
+		     operator & ... d_left (left)
+		     qualified name ... d_right (left)
+		       <names>  */
+
+	      d_print_expr_op (dpi, options, d_left (left));
+	      d_print_comp (dpi, options, d_right (left));
+	    }
+	  else
+	    d_print_comp (dpi, options, left);
+	}
       if (d_right (dc) != NULL)
 	{
 	  size_t len;
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -3990,6 +3990,18 @@ outer(short (*)(int), long)
 _Z6outer2IsEPFilES1_
 outer2<short>(int (*)(long))
 #
+--format=gnu-v3 --no-params
+_ZN1KIXadL_ZN1S1mEiEEE1fEv
+K<&S::m>::f()
+K<&S::m>::f
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1mEiEEE1fEv
+K<1, &S::m>::f()
+# Here the `(int)' argument list of `S::m' is already removed.
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1mEEEE1fEv
+K<1, &S::m>::f()
+#
 # Ada (GNAT) tests.
 #
 # Simple test.

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jason Merrill]

On 06/27/2011 11:04 AM, Jan Kratochvil wrote:
> Had to restrict the patch very much for the template function reference case as
> otherwise the parameter types are required even in templates there.

They should be supressed whenever the function appears in an expression 
context, either as a pointer to member function (i.e. the operand of 
'&') or as the function being called in a call expression.

Jason

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jan Kratochvil]

On Mon, 27 Jun 2011 20:00:24 +0200, Jason Merrill wrote:
> They should be supressed whenever the function appears in an
> expression context, either as a pointer to member function (i.e. the
> operand of '&')

Done, therefore it is no longer restricted only to templates as before.


> or as the function being called in a call expression.

I implemented it in the patch below but I do not agree + understand it.

The call expression is in libiberty/testsuite/demangle-expected modified by
this patch as:

 # decltype/fn call test
 --format=gnu-v3
 _Z4add3IidEDTclL_Z1gEfp_fp0_EET_T0_
-decltype (g({parm#1}, {parm#2})) add3<int, double>(int, double)
+decltype (g) add3<int, double>(int, double)

I agree it is sufficient to determine the return type just from the function
type as return type cannot be overloaded by the function parameters.  But it
no longer matches a valid C++ source code now:

char g (int x, double y) { return 0; }
template <typename T, typename U>
decltype (g((T) 0, (U) 0)) add3 (T x, U y) { return 'z'; }
// error: ‘add3’ declared as function returning a function
// decltype (g) add3 (T x, U y) { return 'z'; }
int main () { add3<int, double> (1, 2.0); }

g++ -Wall -g -std=c++0x
g++ (GCC) 4.7.0 20110629 (experimental)


(Regression testing underway.)


Thanks,
Jan


libiberty/
2011-06-29  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* cp-demangle.c (d_print_comp): Suppress argument list for function
	references by the '&' unary operator.  Keep also already processed
	variant without the argument list.  Suppress argument list also for
	function call used in an expression.
	* testsuite/demangle-expected: Remove parameters from function call
	expressions of 6 testcases.  Create 3 new testcases for function
	references by the '&' unary operator..

--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -4139,7 +4169,46 @@ d_print_comp (struct d_print_info *dpi, int options,
       return;
 
     case DEMANGLE_COMPONENT_UNARY:
-      if (d_left (dc)->type != DEMANGLE_COMPONENT_CAST)
+      if (d_left (dc)->type == DEMANGLE_COMPONENT_OPERATOR
+	  && d_left (dc)->u.s_operator.op->len == 1
+	  && d_left (dc)->u.s_operator.op->name[0] == '&'
+	  && d_right (dc)->type == DEMANGLE_COMPONENT_TYPED_NAME
+	  && d_left (d_right (dc))->type == DEMANGLE_COMPONENT_QUAL_NAME
+	  && d_right (d_right (dc))->type == DEMANGLE_COMPONENT_FUNCTION_TYPE)
+	{
+	  /* Address of a function (therefore in an expression context) must
+	     have its argument list suppressed.
+
+	     unary operator ... dc
+	       operator & ... d_left (dc)
+	       typed name ... d_right (dc)
+		 qualified name ... d_left (d_right (dc))
+		   <names>
+		 function type ... d_right (d_right (dc))
+		   argument list
+		     <arguments>  */
+
+	  d_print_expr_op (dpi, options, d_left (dc));
+	  d_print_comp (dpi, options, d_left (d_right (dc)));
+	  return;
+	}
+      else if (d_left (dc)->type == DEMANGLE_COMPONENT_OPERATOR
+	       && d_left (dc)->u.s_operator.op->len == 1
+	       && d_left (dc)->u.s_operator.op->name[0] == '&'
+	       && d_right (dc)->type == DEMANGLE_COMPONENT_QUAL_NAME)
+	{
+	  /* Keep also already processed variant without the argument list.
+
+	     unary operator ... dc
+	       operator & ... d_left (dc)
+	       qualified name ... d_right (dc)
+		 <names>  */
+
+	  d_print_expr_op (dpi, options, d_left (dc));
+	  d_print_comp (dpi, options, d_right (dc));
+	  return;
+	}
+      else if (d_left (dc)->type != DEMANGLE_COMPONENT_CAST)
 	d_print_expr_op (dpi, options, d_left (dc));
       else
 	{
@@ -4172,10 +4241,11 @@ d_print_comp (struct d_print_info *dpi, int options,
 	  d_print_comp (dpi, options, d_right (d_right (dc)));
 	  d_append_char (dpi, ']');
 	}
-      else
+      /* Function call used in an expression should not have the argument list
+	 printed.  */
+      else if (strcmp (d_left (dc)->u.s_operator.op->code, "cl") != 0)
 	{
-	  if (strcmp (d_left (dc)->u.s_operator.op->code, "cl") != 0)
-	    d_print_expr_op (dpi, options, d_left (dc));
+	  d_print_expr_op (dpi, options, d_left (dc));
 	  d_print_subexpr (dpi, options, d_right (d_right (dc)));
 	}
 
diff --git a/libiberty/testsuite/demangle-expected b/libiberty/testsuite/demangle-expected
index bbd418c..da87282 100644
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -3904,7 +3904,7 @@ decltype ({parm#1}+{parm#2}) add<int, double>(int, double)
 # decltype/fn call test
 --format=gnu-v3
 _Z4add3IidEDTclL_Z1gEfp_fp0_EET_T0_
-decltype (g({parm#1}, {parm#2})) add3<int, double>(int, double)
+decltype (g) add3<int, double>(int, double)
 # new (2008) built in types test
 --format=gnu-v3
 _Z1fDfDdDeDhDsDi
@@ -3916,15 +3916,15 @@ void f<int*, float*, double*>(int*, float*, double*)
 # '.' test
 --format=gnu-v3
 _Z1hI1AIiEdEDTcldtfp_1gIT0_EEET_S2_
-decltype (({parm#1}.(g<double>))()) h<A<int>, double>(A<int>, double)
+decltype (({parm#1}.(g<double>))) h<A<int>, double>(A<int>, double)
 # test for typed function in decltype
 --format=gnu-v3
 _ZN1AIiE1jIiEEDTplfp_clL_Z1xvEEET_
-decltype ({parm#1}+((x())())) A<int>::j<int>(int)
+decltype ({parm#1}+((x()))) A<int>::j<int>(int)
 # test for expansion of function parameter pack
 --format=gnu-v3
 _Z1gIIidEEDTclL_Z1fEspplfp_Li1EEEDpT_
-decltype (f(({parm#1}+(1))...)) g<int, double>(int, double)
+decltype (f) g<int, double>(int, double)
 # lambda tests
 --format=gnu-v3
 _ZZ1giENKUlvE_clEv
@@ -3949,10 +3949,10 @@ _Z1fIfLi4EEvDv_T0__T_
 void f<float, 4>(float __vector(4))
 --format=gnu-v3
 _Z1fI1AEDTclonplfp_fp_EET_
-decltype ((operator+)({parm#1}, {parm#1})) f<A>(A)
+decltype ((operator+)) f<A>(A)
 --format=gnu-v3
 _Z1hI1AEDTcldtfp_miEET_
-decltype (({parm#1}.(operator-))()) h<A>(A)
+decltype (({parm#1}.(operator-))) h<A>(A)
 --format=gnu-v3
 _Z1fDn
 f(decltype(nullptr))
@@ -3990,6 +3990,18 @@ outer(short (*)(int), long)
 _Z6outer2IsEPFilES1_
 outer2<short>(int (*)(long))
 #
+--format=gnu-v3 --no-params
+_ZN1KIXadL_ZN1S1mEiEEE1fEv
+K<&S::m>::f()
+K<&S::m>::f
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1mEiEEE1fEv
+K<1, &S::m>::f()
+# Here the `(int)' argument list of `S::m' is already removed.
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1mEEEE1fEv
+K<1, &S::m>::f()
+#
 # Ada (GNAT) tests.
 #
 # Simple test.

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jason Merrill]

On 06/29/2011 04:00 PM, Jan Kratochvil wrote:
> On Mon, 27 Jun 2011 20:00:24 +0200, Jason Merrill wrote:
>> They should be supressed whenever the function appears in an
>> expression context, either as a pointer to member function (i.e. the
>> operand of '&')
> 
> Done, therefore it is no longer restricted only to templates as before.
> 
>> or as the function being called in a call expression.
> 
> I implemented it in the patch below but I do not agree + understand it.
> 
> The call expression is in libiberty/testsuite/demangle-expected modified by
> this patch as:
> 
>   # decltype/fn call test
>   --format=gnu-v3
>   _Z4add3IidEDTclL_Z1gEfp_fp0_EET_T0_
> -decltype (g({parm#1}, {parm#2})) add3<int, double>(int, double)
> +decltype (g) add3<int, double>(int, double)

Here you're suppressing the arguments to a call, which we want to keep;
we only want to suppress printing the parameter types (which are not
part of the source expression).

Jason

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jan Kratochvil]

On Wed, 29 Jun 2011 22:56:26 +0200, Jason Merrill wrote:
> On 06/29/2011 04:00 PM, Jan Kratochvil wrote:
> > On Mon, 27 Jun 2011 20:00:24 +0200, Jason Merrill wrote:
> >   # decltype/fn call test
> >   --format=gnu-v3
> >   _Z4add3IidEDTclL_Z1gEfp_fp0_EET_T0_
> > -decltype (g({parm#1}, {parm#2})) add3<int, double>(int, double)
> > +decltype (g) add3<int, double>(int, double)
> 
> Here you're suppressing the arguments to a call, which we want to keep;
> we only want to suppress printing the parameter types (which are not
> part of the source expression).

Sorry but what is therefore the expect output in this case?


Thanks,
Jan

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jason Merrill]

On 06/29/2011 05:07 PM, Jan Kratochvil wrote:
> On Wed, 29 Jun 2011 22:56:26 +0200, Jason Merrill wrote:
>> On 06/29/2011 04:00 PM, Jan Kratochvil wrote:
>>> On Mon, 27 Jun 2011 20:00:24 +0200, Jason Merrill wrote:
>>>    # decltype/fn call test
>>>    --format=gnu-v3
>>>    _Z4add3IidEDTclL_Z1gEfp_fp0_EET_T0_
>>> -decltype (g({parm#1}, {parm#2})) add3<int, double>(int, double)
>>> +decltype (g) add3<int, double>(int, double)
>>
>> Here you're suppressing the arguments to a call, which we want to keep;
>> we only want to suppress printing the parameter types (which are not
>> part of the source expression).
>
> Sorry but what is therefore the expect output in this case?

The earlier output was correct.  We just don't want to print "g(int, 
double)".

Jason

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jan Kratochvil]

On Thu, 30 Jun 2011 00:27:31 +0200, Jason Merrill wrote:
> The earlier output was correct.  We just don't want to print "g(int,
> double)".

OK, understood now.  It got more clear with the new testcase:

_Z1tIlEDTplcvT_Li5EclL_Z1qsELi6EEEv

decltype (((long)(5))+((q(short))(6))) t<long>()
->
decltype (((long)(5))+(q(6))) t<long>()

OK to check it in if the regression testing underway is OK?


Thanks,
Jan


libiberty/
2011-06-30  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* cp-demangle.c (d_print_comp): Suppress argument list for function
	references by the '&' unary operator.  Keep also already processed
	variant without the argument list.  Suppress argument list types for
	function call used in an expression.
	* testsuite/demangle-expected: Fix excessive argument list types in
	`test for typed function in decltype'.  New testcase for no argument
	list types printed.  3 new testcases for function references by the
	'&' unary operator..

--- a/libiberty/cp-demangle.c
+++ b/libiberty/cp-demangle.c
@@ -4139,7 +4169,46 @@ d_print_comp (struct d_print_info *dpi, int options,
       return;
 
     case DEMANGLE_COMPONENT_UNARY:
-      if (d_left (dc)->type != DEMANGLE_COMPONENT_CAST)
+      if (d_left (dc)->type == DEMANGLE_COMPONENT_OPERATOR
+	  && d_left (dc)->u.s_operator.op->len == 1
+	  && d_left (dc)->u.s_operator.op->name[0] == '&'
+	  && d_right (dc)->type == DEMANGLE_COMPONENT_TYPED_NAME
+	  && d_left (d_right (dc))->type == DEMANGLE_COMPONENT_QUAL_NAME
+	  && d_right (d_right (dc))->type == DEMANGLE_COMPONENT_FUNCTION_TYPE)
+	{
+	  /* Address of a function (therefore in an expression context) must
+	     have its argument list suppressed.
+
+	     unary operator ... dc
+	       operator & ... d_left (dc)
+	       typed name ... d_right (dc)
+		 qualified name ... d_left (d_right (dc))
+		   <names>
+		 function type ... d_right (d_right (dc))
+		   argument list
+		     <arguments>  */
+
+	  d_print_expr_op (dpi, options, d_left (dc));
+	  d_print_comp (dpi, options, d_left (d_right (dc)));
+	  return;
+	}
+      else if (d_left (dc)->type == DEMANGLE_COMPONENT_OPERATOR
+	       && d_left (dc)->u.s_operator.op->len == 1
+	       && d_left (dc)->u.s_operator.op->name[0] == '&'
+	       && d_right (dc)->type == DEMANGLE_COMPONENT_QUAL_NAME)
+	{
+	  /* Keep also already processed variant without the argument list.
+
+	     unary operator ... dc
+	       operator & ... d_left (dc)
+	       qualified name ... d_right (dc)
+		 <names>  */
+
+	  d_print_expr_op (dpi, options, d_left (dc));
+	  d_print_comp (dpi, options, d_right (dc));
+	  return;
+	}
+      else if (d_left (dc)->type != DEMANGLE_COMPONENT_CAST)
 	d_print_expr_op (dpi, options, d_left (dc));
       else
 	{
@@ -4165,7 +4234,21 @@ d_print_comp (struct d_print_info *dpi, int options,
 	  && d_left (dc)->u.s_operator.op->name[0] == '>')
 	d_append_char (dpi, '(');
 
-      d_print_subexpr (dpi, options, d_left (d_right (dc)));
+      if (strcmp (d_left (dc)->u.s_operator.op->code, "cl") == 0
+          && d_left (d_right (dc))->type == DEMANGLE_COMPONENT_TYPED_NAME)
+	{
+	  /* Function call used in an expression should not have printed types
+	     of the function arguments.  Values of the function arguments still
+	     get printed below.  */
+
+	  const struct demangle_component *func = d_left (d_right (dc));
+
+	  if (d_right (func)->type != DEMANGLE_COMPONENT_FUNCTION_TYPE)
+	    d_print_error (dpi);
+	  d_print_subexpr (dpi, options, d_left (func));
+	}
+      else
+	d_print_subexpr (dpi, options, d_left (d_right (dc)));
       if (strcmp (d_left (dc)->u.s_operator.op->code, "ix") == 0)
 	{
 	  d_append_char (dpi, '[');
--- a/libiberty/testsuite/demangle-expected
+++ b/libiberty/testsuite/demangle-expected
@@ -3920,7 +3920,11 @@ decltype (({parm#1}.(g<double>))()) h<A<int>, double>(A<int>, double)
 # test for typed function in decltype
 --format=gnu-v3
 _ZN1AIiE1jIiEEDTplfp_clL_Z1xvEEET_
-decltype ({parm#1}+((x())())) A<int>::j<int>(int)
+decltype ({parm#1}+(x())) A<int>::j<int>(int)
+# typed function in decltype with an argument list
+--format=gnu-v3
+_Z1tIlEDTplcvT_Li5EclL_Z1qsELi6EEEv
+decltype (((long)(5))+(q(6))) t<long>()
 # test for expansion of function parameter pack
 --format=gnu-v3
 _Z1gIIidEEDTclL_Z1fEspplfp_Li1EEEDpT_
@@ -3990,6 +3994,18 @@ outer(short (*)(int), long)
 _Z6outer2IsEPFilES1_
 outer2<short>(int (*)(long))
 #
+--format=gnu-v3 --no-params
+_ZN1KIXadL_ZN1S1mEiEEE1fEv
+K<&S::m>::f()
+K<&S::m>::f
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1mEiEEE1fEv
+K<1, &S::m>::f()
+# Here the `(int)' argument list of `S::m' is already removed.
+--format=gnu-v3
+_ZN1KILi1EXadL_ZN1S1mEEEE1fEv
+K<1, &S::m>::f()
+#
 # Ada (GNAT) tests.
 #
 # Simple test.

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jason Merrill]

OK.

Jason

Re: [gcc patch] Re: C++ member function template id not matching linkage name (PR debug/49408)

[Jan Kratochvil]

On Fri, 01 Jul 2011 18:27:36 +0200, Jason Merrill wrote:
> OK.

Checked in:
	http://gcc.gnu.org/viewcvs?view=revision&revision=175761

No regressions on gcc-4.6.1-1.fc15.x86_64 (it is not trunk but hopefully
similar enough).


Thanks,
Jan