This is the mail archive of the
mailing list for the GCC project.
Re: C++ demangler fix
- From: Gary Benson <gbenson at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, DJ Delorie <dj at redhat dot com>, Ian Lance Taylor <ian at airs dot com>
- Date: Wed, 11 Sep 2013 13:49:46 +0100
- Subject: Re: C++ demangler fix
- Authentication-results: sourceware.org; auth=none
- References: <20130904142943 dot GA18972 at blade dot nx> <20130910153400 dot GC1817 at tucnak dot redhat dot com>
Jakub Jelinek wrote:
> cp-demangle.c isn't used just in libiberty, where using hashtab,
> xcalloc, XNEW etc. is fine, but also in libsupc++/libstdc++, where
> none of that is fine. That is why cp-demangle.c only uses
> e.g. realloc, checks for allocation failures and propagates those to
> the caller if they happen (see allocation_failure field). hashtab.o
> isn't linked into libstdc++ nor libsupc++, and the question is if we
> really do want to link all the hashtable code into libstdc++.
> How many hash table entries are there typically? Is a hashtable
Three entries were required for the symbol in the testcase:
I don't think there will many symbols with very many entries required.
I'm guessing that most symbols will require zero (which is why I made
it defer hashtable creation until it was required).
What kind of data structure would you like to see here, a realloc'd
array? Do libsupc++ and libstdc++ use the demangler for anything more
performance-sensitive than exception printing?