Created attachment 7712 [details] Repro-Case The following symbol fails to demangle with GDB 7.7.1 (built from source.) Comes from Code compiled with GCC 4.8.2 on Ubuntu 14.04. Also fails on distro-provided GDB (7.7.) "_ZNK5niven5ColorIfLi4EEdvIfEENSt9enable_ifIXsrSt13is_arithmeticIT_E5valueEKNS0_IDTmlcvS5__Ecvf_EELi4EEEE4typeES5_" c++filt correctly demangles this to: std::enable_if<std::is_arithmetic<float>::value, niven::Color<decltype (((float)())*((float)())), 4> const>::type niven::Color<float, 4>::operator/<float>(float) const For the repro-case, assuming it has been put into the GDB source root directory and GDB is built, use: gcc -Iinclude/ test.c ./libiberty/libiberty.a -o test
Confirmed and filed as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61805
Ok, this problem is a bit more complicated. First, a newer GCC (4.9.1) and Clang 3.5 doesn't produce the symbol any more. Running a more recent c++filt on it now crashes c++filt -- if you look closely, the originally demangled type was also incorrect, as: decltype (((float)()*(float)())) does not make sense -- should have been decltype (float ()*float ()) which is simply float. I'm debugging a new crash now where the demangler/libiberty starts producing a symbol name with decltype in it, which I strongly suspect is similar to the original issue. Am I right to assume that decltype is never part of a mangled symbol name?
It might be best to add your comments to the GCC bug above, it's more likely to be seen by those with the right kind of expertise.
Was fixed on gcc side some time ago.