analysis of libiberty/cp-demangle.c for libsupc++/__cxa_demangle

[Mark Mitchell]

Benjamin Kosnik wrote:

> An experimental patch to use the libiberty cp-demangle routines in
> libsupc++/__cxa_demangle is attached. An additional (small) patch is
> needed for libiberty/cp-demangle.c.
> 
> I have 4 new fails when it's used. 
> 
> FAIL: demangle/abi_examples/01.cc execution test
> FAIL: demangle/abi_examples/02.cc execution test
> string: f
> libiberty: float
> libstdc++: f
> 
> I think libiberty is pretty clearly wrong here, just based on the C++ ABI docs.

Yes.  Ian, would you please fix that?

> FAIL: demangle/regression/cw-11.cc execution test
> string: _X11TransParseAddress
> libiberty: _X11TransParseAddress, -2: invalid mangled name
> libstdc++: _X11TransParseAddress
> 
> Same: this is twisted, but not invalid.

Again, I agree.  The -2 return code should really only be used for names 
that start with _Z, but cannot be demangled.  I'm not arguing that this 
is necessarily great interface design, or that the ABI is very clear 
about what to do, but that's what I think it is trying to say.

In hindsight, it would be much better if there were a parameter to 
indicate whether the caller wants to demangle a type name or a 
function/object name.

> FAIL: demangle/regression/cw-16.cc execution test
> string: _Z3fooIA6_KiEvA9_KT_rVPrS4_
> libiberty:void foo<int const [6]>(int const ( const [9]) [6], int const ( const ( restrict* volatile restrict) [9]) [6])
> libstdc++:void foo<int const [6]>(int const [9][6], int const restrict (* volatile restrict) [9][6])

This test case is slightly bogus in that top-level cv-qualifiers never 
appear on function types, and, therefore, the compiler should never 
produce the innermost "volatile restrict" qualification on the second 
parameter.  However, given that mangled name, the libstdc++ demangler is 
doing the right thing, and the libiberty version is not.

This is an inevitable consequence of having had two demanglers and two 
demangler testsuites; I'm glad that we're rectifying that now.

Ian, would you look at this as well?

Benjamin, I guess it's best to hold off on your patch until these issues 
are resolved, just so as not to create new confusing FAILs for people.

Thank you for working on the patch.  Hopefully we can get these failures 
fixed in short order.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com