[gcc patch 0/3] libiberty: New DMGL_RET_DROP

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

Hi,

introducing DMGL_RET_DROP which suppresses return type demangled from linkage
name for the toplevel function type.

DMGL_RET_POSTFIX is now in use only for DMGL_JAVA.  Besides Java return types
in linkage name are in C++ present for function templates.

GDB since 7.2 provides convenience alias for the function template symbols
without the return type so that for
	0000000000400523 T _Z4funcIdET_i
	0000000000400523 T double func<double>(int)
one can since GDB 7.2 easily find the template functions by name using:
	(gdb) break fun<tab-completion>
instead of having to guess the return type first as in GDB 7.1:
	(gdb) break 'double fun<tab-completion>

As the demangler usage has been reintroduced for GDB 7.3 (to fix GDB PR 12506
and similar cases by using DW_AT_linkage_name again) it now needs to drop the
return type by the demangler (instead of a GDB 7.2 custom physname code).

The function templates return types linkage name are a similar case like
DMGL_JAVA which uses DMGL_RET_POSTFIX:
	jmain.main(java.lang.String[])void
I believe both cases should either use DMGL_RET_POSTFIX or the new
DMGL_RET_DROP, therefore to use just:
	jmain.main(java.lang.String[])
For C++ I (and also Tom Tromey) prefer DMGL_RET_DROP:
	func<double>(int)
over DMGL_RET_POSTFIX:
	func<double>(int)double
as in practice there are no two template function instances with the same name
+ parameters signature but different return type - one cannot overload
function by return type in either C++ or Java.  G++ rejects compilation of
a CU containing such two instances, one can only link two different CUs
together to get the return type linkage name difference in a single file.

After all one also still can reference the function by its original ELF symbol
'double func<double>(int)'.  Proposing in a different GDB patch to use
DMGL_RET_DROP even for Java symbols but I do not have any real need for it.

This patchset had no GCC regressions for Fedora gcc-4.6.0-8.fc15 (not tested
for GCC HEAD, hopefully OK).

The new testcases are based on a C++ source:

template <typename T>
char outer (int (*inner) (long)) { return 0; }
int outer2_ret (long) { return 0; }
template <typename T>
int (*outer2 (int (*inner) (long))) (long) { return outer2_ret; }
char outer (short (*inner) (int), long) { outer2<short> (0); return
outer<short> (0);  }


Thanks,
Jan