Bug 28797 - Problems with demangling (__cxa_demangle())
Summary: Problems with demangling (__cxa_demangle())
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.0.1
: P3 normal
Target Milestone: 4.2.0
Assignee: Ian Lance Taylor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-22 03:57 UTC by Kurkov, Vasiliy
Modified: 2007-01-10 19:40 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-08-26 19:04:39


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kurkov, Vasiliy 2006-08-22 03:57:42 UTC
I used a simple program which calls __cxa_demangle function. These mangled
names were demangled wrong:
_Z1fA37_iPS_ -> f(int [37], int (*) [37]), should be: f(int[37], int (*) [37])
_Z1fILi2EEvRAplplT_Li3ELi1E_i -> void f<2>(int (&) [((2) + (3)) + (1)]), should be: void f<2>(int (&) [((2)+(3))+(1)])
_Z1fM1AKiPKS1_ -> _Z1fM1AKiPKS1_, should be: f(int const A::*, int const A::* const*)
_Z3absILd1c1f1496f8a44219EEvv -> void abs<(double)[1c1f1496f8a44219]>(), should be: void abs<3.14159e-173>()
_Z3absILd40092acd9e83e426EEvv -> void abs<(double)[40092acd9e83e426]>(), should be: void abs<3.1459>()			
_Z3absILe08042191a6cc56a2fe117becEEvv -> void abs<(long double)[08042191a6cc56a2fe117bec]>(), should be: void abs<1.234e-2345l>()
_Z3absILe804bfff8000000000000000EEvv -> void abs<(long double)[804bfff8000000000000000]>(), should be: void abs<-1l>()			
_Z3absILf4016147bEEvv -> void abs<(float)[4016147b]>(), should be: void abs<2.345f>()			
_Z3absILfc1800000EEvv -> void abs<(float)[c1800000]>(), should be: void abs<-16f>()			
_Z3fooA30_A_i -> foo(int [30][]), should be: foo(int[30][])
_Z9function1PVKiPViPKiPi -> function1(int const volatile*, int volatile*, int const*, int*), should be: function1(int volatile const*, int volatile*, int const*, int*)
_Z9function2PVKiPViPKiRS_RS1_RS3_ -> function2(int const volatile*, int volatile*, int const*, int const volatile&, int volatile&, int const&), should be: function2(int volatile const*, int volatile*, int const*, int volatile const&, int volatile&, int const&)
_Z9function4PVKi -> function4(int const volatile*), should be: function4(int volatile const*)
_Z9function5PVKi -> function5(int const volatile*), should be: function5(int volatile const*)
_Z9function6PVKiS0_ -> function6(int const volatile*, int const volatile*), should be: function6(int volatile const*, int volatile const*)
_Z9functionjj -> functionj(unsigned int), should be functionj(unsigned)
_ZlsRKU3fooU4bart1XS0_ -> operator<<(X bart foo const&, X bart), should be: operator<<(X const foo bart&, X const foo bart)
_ZN3FooIA4_iE3barE -> Foo<int [4]>::bar, should be: Foo<int[4]>::bar
_Znaj -> operator new[](unsigned int), should be: operator new[](unsigned)
_ZngILi42EEvN1AIXplT_Li2EEE1TE -> void operator-<42>(A<(42) + (2)>::T), should be: void operator-<42>(A<(42)+(2)>::T)
_ZngILi42EEvN1AIXplT_Li2EEEE -> void operator-<42>(A<(42) + (2)>), should be: void operator-<42>(A<(42)+(2)>)
_ZNSsC1EPKcRKSaIcE -> std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&), should be: std::string::string(char const*, std::allocator<char> const&)
_Znwj -> operator new(unsigned int), should be: operator new(unsigned)
_ZTv0_n16_NSoD0Ev -> virtual thunk to std::basic_ostream<char, std::char_traits<char> >::~basic_ostream(), should be: virtual thunk to std::ostream::~ostream()

These issues you can reproduce on Mac OS, IA32 Linux and EM64T Linux

Environment: IA32 and EM64T Linux: Red Hat Enterprise Linux WS release 4 (Nahant Update 3); Release: gcc version 3.4.5 20051201 (Red Hat 3.4.5-2)

Environment: Mac OS
Release: 
gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5341.obj~1/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-arch=pentium-m --with-tune=prescott --program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5341)

How-To-Repeat:
Feed those mangled names to __cxa_demangle() function and check the results of
demangling.

This report is very close to Bug#:7986.
Comment 1 Andrew Pinski 2006-08-22 05:21:06 UTC
_Z1fA37_iPS_ -> f(int [37], int (*) [37]), should be: f(int[37], int (*) [37])
Isn't that just a space?

_Z1fILi2EEvRAplplT_Li3ELi1E_i -> void f<2>(int (&) [((2) + (3)) + (1)]), should
be: void f<2>(int (&) [((2)+(3))+(1)])

Likewise?

_Z3fooA30_A_i -> foo(int [30][]), should be: foo(int[30][])

Likewise?

_Z9function1PVKiPViPKiPi -> function1(int const volatile*, int volatile*, int
const*, int*), should be: function1(int volatile const*, int volatile*, int
const*, int*)

The older of the volatile and const does not matter so why is this a problem?

_Z9functionjj -> functionj(unsigned int), should be functionj(unsigned)

unsigned == unsigned int so why is this a problem?

_ZTv0_n16_NSoD0Ev -> virtual thunk to std::basic_ostream<char,
std::char_traits<char> >::~basic_ostream(), should be: virtual thunk to
std::ostream::~ostream()

no, it is still basic_ostream<char, std::char_traits<char> > technicially.


And some more space issues.

The double ones are weird, maybe we should print out the C99 hex float instead, there is a bug about this before too.
Comment 2 Andrew Pinski 2006-08-22 05:26:14 UTC
(In reply to comment #1)
> The double ones are weird, maybe we should print out the C99 hex float instead,
> there is a bug about this before too.

See PR 13045, there is most likely more discussion about this.   The other issue is that demangling for floats are hard between different targets because of different floating point formats.
Comment 3 Kurkov, Vasiliy 2006-08-22 05:52:08 UTC
(In reply to comment #1)
Sorry for space and unsigned int issues, I should just correct compare files for my test.
Comment 4 Ian Lance Taylor 2006-08-24 06:20:26 UTC
Where did you get your list of symbol names and demangled strings?

As Andrew has pointed out, there seem to be a few different issues here: different spacing, different qualifier order, different handling of floating point constants.  It may well be appropriate to change gcc's demangler, but in my opinion these different issues should be handled as different problem reports.

Other than those issues, I see one serious issue in this list: _Z1fM1AKiPKS1_, which the gcc demangler does not demangle, but you propose should be demangled as f(int const A::*, int const A::*const*).  I have to agree with you that there appears to be something wrong with the demangler in this case.  It is related to the long comment in d_pointer_to_member_type in cp-demangle.c.  When I wrote that comment I believed that it was correct.  However, it appears to now be incorrect.  I haven't yet been able to track down the change to gcc which affected this.  It is also possible that I was simply mistaken.
Comment 5 Kurkov, Vasiliy 2006-08-25 08:50:37 UTC
(In reply to comment #4)
> Where did you get your list of symbol names and demangled strings?
My program uses C standard I/O routines instead of iostreams, to support new-ABI C++ compilers that do not have complete C++ standard library implementations.
Comment 6 Ian Lance Taylor 2006-08-26 18:54:12 UTC
OK, so that's where you got your symbols, but where did you get your list of demangled strings?  Did you just compare directly to the source code?  Or are you using some other demangler?
Comment 7 Ian Lance Taylor 2006-08-26 19:04:39 UTC
I am testing a patch to the demangler to correctly handle _Z1fM1AKiPKS1_.
Comment 8 ian@gcc.gnu.org 2006-08-27 21:43:03 UTC
Subject: Bug 28797

Author: ian
Date: Sun Aug 27 21:42:55 2006
New Revision: 116493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116493
Log:
	PR other/28797
	* cp-demangle.c (d_pointer_to_member_type): Do add a substitution
	for a qualified member which is not a function.
	* testsuite/demangle-expected: Add test case.

Modified:
    trunk/libiberty/ChangeLog
    trunk/libiberty/cp-demangle.c
    trunk/libiberty/testsuite/demangle-expected

Comment 9 Ian Lance Taylor 2006-08-27 21:44:13 UTC
I'm going to close this PR since I just fixed the only real problem that I see here.  If you see other problems with the demangler, please open a separate PR for each problem.

Thanks for reporting the bug.