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

[Gabriel Dos Reis]

On Wed, Jun 22, 2011 at 10:42 AM, 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.
>
> For this case,
>
>> The function linkage name has prefix: K<&(S::m(int))>
>
> This isn't actually valid C++ syntax, so the demangler should be adjusted.

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.

-- Gaby

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

[Jason Merrill]

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.


For this case,


The function linkage name has prefix: K<&(S::m(int))>


This isn't actually valid C++ syntax, so the demangler should be adjusted.


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.


Jason

C++ member function template id not matching linkage name (PR debug/49408)

[Jan Kratochvil]

Hi,

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49408

struct S {
  void m (int x) {}
};
template
struct K {
  void f () { S s; (s.*F) (5); }
};
int main () {
  K<&S::m> k;
  k.f ();
}

 <1><64>: Abbrev Number: 8 (DW_TAG_structure_type)
<65>   DW_AT_name: K<&S::m>
 ^
vs.
004004de W K<&(S::m(int))>::f()
 

The function linkage name has prefix: K<&(S::m(int))>
But DW_AT_name of that struct is: K<&S::m>
They do not match.

But the struct DW_AT_name corresponds to the source literal 'K<&S::m>'.
So maybe the function linkage name should be changed to: 'K<&S::m>::f()'.
But changing the function linkage name would break ABI.

OTOH the function linkage name should probably refer to the fully qualified
'S::m' overload - to be able to look up 'S::m(int)' from the linkage name:

_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 --- important to find 'S::m(int)'
  argument list   --- important to find 'S::m(int)'
builtin type int  --- important to find 'S::m(int)'
name 'f'
  function type
argument list


Or maybe it is not a bug and one just has to accept the function prefix may
not match its struct/class name?

Deciding how to deal with the GDB testcase:
gdb.cp/temargs.exp: test type of F in k2_m


Thanks for advice,
Jan