If I compile this C++ file with current mainline template<bool B> class H { public: enum T { V = B }; }; template <typename T> class C { public: enum { B1 = true, B2 = false }; }; template<typename T> void f(typename H<C<T>::B1 && !C<T>::B2>::T) {} void g() { f<int>(H<true>::V); } I get this symbol: _Z1fIiEvN1HIXaasr1CIT_E2B1ntsrS3_2B2EE1TE I believe that this symbol is not mangled according to the current C++ mangling ABI. The relevant part is the expression Xaasr1CIT_E2B1ntsrS3_2B2E, specifically the local name sr1CIT_E2B1. The mangling ABI says <unresolved-name> ::= [gs] <base-unresolved-name> ::= sr <unresolved-type> <base-unresolved-name> ::= srN <unresolved-type> <unresolved-qualifier-level>+ E <base-unresolved-name> ::= [gs] sr <unresolved-qualifier-level>+ E <base-unresolved-name> <unresolved-type> ::= <template-param> ::= <decltype> ::= <substitution> The string after "sr" is 1CIT_E2B1. The 1C is not a template-param, a decltype, or a substitution. Therefore we must be using the fourth expansion of <unresolved-name>, where we expect to see a series of <unresolved-qualifier-level> entries, followed by an E, followed by a <base-unresolved-name>. But in fact what we see here is <type> <unqualified-name>. This is what the code in cp/mangle.c outputs: write_string ("sr"); write_type (scope); write_member_name (member); Either the mangling ABI or GCC itself is wrong.
For the record, when the same file is compiled with clang, the symbol is _Z1fIiEvN1HIXaasr1CIT_EE2B1ntsr1CIS1_EE2B2EE1TE . This symbol does appear to follow the current API. The relevant part of the expression here is sr1CIT_EE2B1 .
Related to the upstream ABI issue: https://github.com/itanium-cxx-abi/cxx-abi/issues/38 related to PR 88413 and PR 89818 .
*** Bug 85648 has been marked as a duplicate of this bug. ***
*** Bug 88413 has been marked as a duplicate of this bug. ***
*** Bug 89818 has been marked as a duplicate of this bug. ***
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:58fb912c15175f4444144b8a4ab52a4880b84994 commit r11-6300-g58fb912c15175f4444144b8a4ab52a4880b84994 Author: Jason Merrill <jason@redhat.com> Date: Mon Dec 21 17:36:25 2020 -0500 c++: Fix demangling of <unresolved-name> The ABI for unresolved scoped names on the RHS of . and -> used to be sr <type> <unqualified-id> That changed years ago to something more complex, but G++ was never updated. This change was particularly incompatible for simple qualified-ids like A::x, which were previously mangled as sr1A1x, and now sr1AE1x. This obviously makes life hard for demanglers, which can't know whether to consume that E or not. To work around this, we now try demangling with the newer ABI, and if that fails and we saw an "sr", try again with the older ABI. libiberty/ChangeLog: PR c++/67343 * cp-demangle.h (struct d_info): Add unresolved_name_state. * cp-demangle.c (d_prefix): Add subst parm. (d_nested_name): Pass it. (d_unresolved_name): Split out from... (d_expression_1): ...here. (d_demangle_callback): Maybe retry with old sr mangling. * testsuite/demangle-expected: Add test.
Created attachment 49828 [details] WIP Fix Here's my current patch for this bug, but I think I'm going to hold off on it pending the resolution of ABI issue 38.
Created attachment 49829 [details] Follow-on patch And this one fixes ->:: according to the current ABI, but also holding for the issue resolution.
*** Bug 109887 has been marked as a duplicate of this bug. ***