Re: analysis of libiberty/cp-demangle.c forlibsupc++/__cxa_demangle

[Benjamin Kosnik <bkoz at redhat dot com>]

>> 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.
>
>I have fixed the libiberty demangler so that it returns an error
>status of -2 for this case.  The libstdc++-v3 test case will still
>fail, but, as discussed, I think it is defensible to change the tests
>to:
>  verify_demangle("f", "error code = -2: invalid mangled name");

Thanks.

I also think your position here is defensible, although certainly not
what we'd been doing previously.

Future iterations of the C++ ABI document will hopefully resolve this
conclusively, along with other odd bits and improvements.

>> 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.
>
>As discussed, I think the libiberty demangler is behaving correctly
>here.

As above.

>> 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 is based on libstdc++/12736. 
>> See http://gcc.gnu.org/ml/libstdc++/2003-10/msg00222.html
>
>I have fixed this bug.  The output is now the same as the libstdc++-v3
>demangler, except that the libiberty demangler prints "restrict const"
>instead of "const restrict".

I think that's acceptable.

>With the libiberty demangler which is currently on mainline, and
>Benjamin's patch to use it in libstdc++-v3, the appended patches
>permit the libstdc++-v3 testsuite to run with no demangling errors.

Thanks.

>Besides the cases discussed above, there is a difference where the
>libstdc++-v3 demangler prints [extern "C"] and the libiberty demangler
>prints nothing.  Historically the libiberty demangler has only printed
>[extern "C"] when in verbose mode.  In fact, the current libiberty
>demangler never prints it.  I don't personally consider this to be
>particularly serious; I think the testcase below shows that the
>notation is relatively useless.

Yep. This is not something I'm worried about.

-benjamin