This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: analysis of libiberty/cp-demangle.c forlibsupc++/__cxa_demangle
The patch I posted earlier was merely a feasibility study.
>If it is decided to keep the demangler, then I surely hope it won't be
>removed "tomorrow" (or in 3.5, or 3.6): I don't like code duplication,
>and once it is a part of libstdc++ I will start to use it from there and
>remove it from libcwd (as such providing a garantee for maintenance and
>testing too). You understand that I am reluctant to do this unless it
>becomes a more or less permanent extension to libstdc++.
I think Ian, Gaby, Phil, and I at least would like to see your demangler
remain in the libstdc++ sources. As Ian has indicated, there are
advantages, not disadvantages, to having two different but correct
demangler implementations. Also, the C++ demangler does have unique
features that are not part of the libiberty demangler.
The immediate, must-solve problem we are having is with having
__cxa_demangle as a self-contained part of libsupc++. I don't see a way
to have this functionality and use the C++ demangler.
I propose the following:
1) your patch of yesterday + my patches to add an type parameter get
applied to demangle.h.
2) this gets moved to include/ext/demangle.h
3) We move __cxa_demangle into libsupc++ and use libiberty's code for this function.
Thoughts? Is this acceptable to everybody?
-benjamin