Re: Slow handling of C++ symbol names

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

Ian Lance Taylor writes:
> Could you extract a few of the larger demangled names from each version,
> and post them?  It might be a good double-check that something isn't
> weirdly broken.

I'm working on it.

I'm writing a Perl script to pass each name through both demanglers,
strip the differences, and compare the results.  There are a lot of
picky differences to account for.

So far I've found one type of difference that looks like a bug in the
new demangler.

  _ZStltI9file_pathSsEbRKSt4pairIT_T0_ES6_
  OLD: bool std::operator< <file_path, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >(std::pair<file_path, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&, std::pair<file_path, std::basic_string<char, > std::char_traits<char>, std::allocator<char> > > const&)
  NEW: bool std::operator<<file_path, std::string>(std::pair<file_path, std::string> const&, std::pair<file_path, std::string> const&)

The old demangler produces "operator< <", and the new demangler produces
"operator <<".  I'm not a name mangling expert but I think that
"operator <" is correct here and the new demangler suffers from
shift-operator-versus-template-syntax gotcha.

Also, why do you want the demangled names?  I would think you would
have the same old+new demanglers that I do, so that the mangled names
would suffice.  My reason is that the mangled names which are different
amount to 3 megabytes or so, but the demangled names which are different
amount to 300 megabytes or so.

Michael C