Created attachment 40931 [details] demangler failure list The demangler currently doesn't demangle any of the symbols in the attached file: % c++filt < demangler_failures llvm-cxxfilt correctly demangles most of them. The list was generated by using Pedro's mangler/demangler dogfooding patch https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02277.html and then building gcc, llvm and Firefox with patched gcc trunk.
Created attachment 40932 [details] Pedro's patch updated for trunk
Thanks for looking at that! I'd love for that patch to me merged, but realistically, I don't know when I'd have time to champion it, and it's been almost 3 years... If someone picks it up and runs with it, it's much appreciated. FYI, Jason provided feedback in the following month: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00082.html but I never followed through, and I have no other local changes.
The patch slows down the compiler immensely, so I don't think it should be enabled by flag_checking. A new -enable-checking= option would be best. I will test if Jason's suggestion makes any difference.
That's a good point. Maybe a mangling/demangling hash/cache would help with that, though can't beat 0 work.
Created attachment 40935 [details] list of testsuite demangler failures
Jason's idea doesn't help much. For the demangler failures of the testsuite there are only 9 less (<2%).
One big chunk of failures is due to the following: markus@x4 tmp % cat mangl.ii struct C; template <class T> struct B { template <class U> operator B<U>(); T *operator->(); }; struct D { B<C> tmp; template <class T> void m_fn1(T p1) { tmp = p1; } }; struct E; void fn1() { B<D> l; B<E> m; l->m_fn1(m); } markus@x4 tmp % g++ -O2 -c mangl.ii && nm -C mangl.o 0000000000000000 T fn1() U B<D>::operator->() U _ZN1BI1EEcvS_IT_EI1CEEv markus@x4 tmp % llvm-cxxfilt _ZN1BI1EEcvS_IT_EI1CEEv B<E>::operator B<C><C>() The second <C> in "B<C><C>" is not handled.