This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: analysis of libiberty/cp-demangle.c for libsupc++/__cxa_demangle
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: ian at wasabisystems dot com, libstdc++ at gcc dot gnu dot org
- Date: Mon, 23 Feb 2004 16:06:09 -0800
- Subject: Re: analysis of libiberty/cp-demangle.c for libsupc++/__cxa_demangle
- Organization: CodeSourcery, LLC
- References: <20040223170416.7a0ab854.bkoz@redhat.com>
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