https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70182
--- Comment #9 from Ian Lance Taylor <ian at airs dot com> --- Yes. The relevant bits in the mangling ABI are <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> <base-unresolved-name> ::= <simple-id> ::= on <operator-name> ::= on <operator-name> <template-args> ::= dn <destructor-name> <unresolved-qualifier-level> ::= <simple-id> <simple-id> ::= <source-name> [ <template-args> ] <source-name> ::= <positive length number> <identifier> srT_ must be sr <unresolved-type> <base-unresolved-name>, where the T_ is the <unresolved-type>, so it must be followed by <base-unresolved-name>. <base-unresolved-name> can only start with a digit or "on" or "dn". So I see no way that srT_cl could meet the requirements of the ABI. It has to be srT_oncl, where the "on" is needed to indicate that "cl" is an operator name. That said, GCC is not crazy, as there is no other way to parse this. The result is unambiguous. But it doesn't meet the documented standard. I think the bug may be that cp/mangle.c:write_member_name needs to check IDENTIFIER_OPNAME_P and print "on" if it is true, as write_expression does. But I'm not sure.