-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unresolved-names with resolved prefixes #38
Comments
Another example:
Clang mangles |
This is being discussed on the GCC bug tracker -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 |
Effectively, GCC is using a non-standard
production to get the results you're seeing, as a generalization of the standard
productions. This seems to me to be more consistent than the standard
production, and has the benefit of getting the usual substitution behavior. I would just grumble and fix my compiler if not for @zygoloid's point that the standard behavior leads to mangling collisions. I think we do need to mangle the enclosing scope, and could do that for affected code either the GCC way or by adding more |
This also affects fully-resolved names like (Note that GCC currently omits the std:: entirely, I'm looking at these issues in the context of fixing that bug) |
Looking back at when this grammar was introduced in 2010 ("Proposed ABI changes for new C++0x SFINAE rules"), I see that previously the mangling was
And that's what G++ still uses. The rationale for the change was handling names on the RHS of . and ->, where (we have now reaffirmed that) lookup of the first name needs to happen in the scope of the object expression, and so all we have is a sequence of names. There wasn't really any discussion back then about applying this change to qualified-ids outside of class member access expressions, and I think doing so was a mistake. The old mangling is still better in other contexts, as demonstrated by Richard's original post above; we know the exact scope, so how it was written is not relevant to declaration matching or SFINAE, but uniquely identifying the named entity is. The other problem with the change is that it created an ambiguity between the old and new manglings: A::x was mangled as If we're going to change the mangling ABI for qualified-ids outside class member access expressions anyway, to mangle the resolved scope instead of the written scope, I think it makes sense to express the scope the same way we do elsewhere, i.e. as The smallest change for G++ would be to revert the change for names with known scope, and change the mangling for qualified-ids in a class member access expression:
But this would reintroduce the demangler confusion, so it's probably not a good choice. Alternatively, we could introduce a distinct mangling for the
Incidentally, it seems to me that [gs] is only needed to distinguish Alternatively, we could continue with the current mangling grammar, and only say that we mangle the full scope. That would avoid changing the ABI for names that are explicitly fully-qualified, but I don't know how useful that is; in libstdc++, at least, the only mangled names that use |
Or, instead of
The third rule could be replaced by a note that the This shouldn't require any changes to currently conforming demanglers. |
I think If I might summarize the discussion above, it seems like we have this:
So we need to find a way to mangle scope qualifiers on unresolved names with as much of the name resolved as possible, and we need to do it without introducing ambiguities, and ideally we don't change existing manglings too much. Fundamentally I think that leaves us with Jason's idea of going back to |
Per itanium-cxx-abi/cxx-abi#24 and itanium-cxx-abi/cxx-abi#166 We need to mangle constraints to be able to distinguish between function templates that only differ in constraints. From the latter link, we want to use the template parameter mangling previously specified for lambdas to also make explicit the form of a template parameter where the argument is not a "natural" fit for it, such as when the parameter is constrained or deduced. I'm concerned about how the latter link changes the mangling for some C++98 and C++11 patterns, so I've limited template_parm_natural_p to avoid two cases found by running the testsuite with -Wabi forced on: template <class T, T V> T f() { return V; } int main() { return f<int,42>(); } template <int i> int max() { return i; } template <int i, int j, int... rest> int max() { int sub = max<j, rest...>(); return i > sub ? i : sub; } int main() { return max<1,2,3>(); } A third C++11 pattern is changed by this patch: template <template <typename...> class TT, typename... Ts> TT<Ts...> f(); template <typename> struct A { }; int main() { f<A,int>(); } I aim to resolve these with the ABI committee before GCC 14.1. We also need to resolve itanium-cxx-abi/cxx-abi#38 (mangling references to dependent template-ids where the name is fully resolved) as references to concepts in std:: will consistently run into this area. This is why mangle-concepts1.C only refers to concepts in the global namespace so far. The library changes are to avoid trying to mangle builtins, which fails. Demangler support and test coverage is not complete yet. gcc/cp/ChangeLog: * cp-tree.h (TEMPLATE_ARGS_TYPE_CONSTRAINT_P): New. (get_concept_check_template): Declare. * constraint.cc (combine_constraint_expressions) (finish_shorthand_constraint): Use UNKNOWN_LOCATION. * pt.cc (convert_generic_types_to_packs): Likewise. * mangle.cc (write_constraint_expression) (write_tparms_constraints, write_type_constraint) (template_parm_natural_p, write_requirement) (write_requires_expr): New. (write_encoding): Mangle trailing requires-clause. (write_name): Pass parms to write_template_args. (write_template_param_decl): Factor out from... (write_closure_template_head): ...here. (write_template_args): Mangle non-natural parms and requires-clause. (write_expression): Handle REQUIRES_EXPR. include/ChangeLog: * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CONSTRAINTS. libiberty/ChangeLog: * cp-demangle.c (d_make_comp): Handle DEMANGLE_COMPONENT_CONSTRAINTS. (d_count_templates_scopes): Likewise. (d_print_comp_inner): Likewise. (d_maybe_constraints): New. (d_encoding, d_template_args_1): Call it. (d_parmlist): Handle 'Q'. * testsuite/demangle-expected: Add some constraint tests. libstdc++-v3/ChangeLog: * include/std/bit: Avoid builtins in requires-clauses. * include/std/variant: Likewise. gcc/testsuite/ChangeLog: * g++.dg/abi/mangle10.C: Disable compat aliases. * g++.dg/abi/mangle52.C: Specify ABI 18. * g++.dg/cpp2a/class-deduction-alias3.C * g++.dg/cpp2a/class-deduction-alias8.C: Avoid builtins in requires-clauses. * g++.dg/abi/mangle-concepts1.C: New test. * g++.dg/abi/mangle-ttp1.C: New test.
Per itanium-cxx-abi/cxx-abi#24 and itanium-cxx-abi/cxx-abi#166 We need to mangle constraints to be able to distinguish between function templates that only differ in constraints. From the latter link, we want to use the template parameter mangling previously specified for lambdas to also make explicit the form of a template parameter where the argument is not a "natural" fit for it, such as when the parameter is constrained or deduced. I'm concerned about how the latter link changes the mangling for some C++98 and C++11 patterns, so I've limited template_parm_natural_p to avoid two cases found by running the testsuite with -Wabi forced on: template <class T, T V> T f() { return V; } int main() { return f<int,42>(); } template <int i> int max() { return i; } template <int i, int j, int... rest> int max() { int sub = max<j, rest...>(); return i > sub ? i : sub; } int main() { return max<1,2,3>(); } A third C++11 pattern is changed by this patch: template <template <typename...> class TT, typename... Ts> TT<Ts...> f(); template <typename> struct A { }; int main() { f<A,int>(); } I aim to resolve these with the ABI committee before GCC 14.1. We also need to resolve itanium-cxx-abi/cxx-abi#38 (mangling references to dependent template-ids where the name is fully resolved) as references to concepts in std:: will consistently run into this area. This is why mangle-concepts1.C only refers to concepts in the global namespace so far. The library changes are to avoid trying to mangle builtins, which fails. Demangler support and test coverage is not complete yet. gcc/cp/ChangeLog: * cp-tree.h (TEMPLATE_ARGS_TYPE_CONSTRAINT_P): New. (get_concept_check_template): Declare. * constraint.cc (combine_constraint_expressions) (finish_shorthand_constraint): Use UNKNOWN_LOCATION. * pt.cc (convert_generic_types_to_packs): Likewise. * mangle.cc (write_constraint_expression) (write_tparms_constraints, write_type_constraint) (template_parm_natural_p, write_requirement) (write_requires_expr): New. (write_encoding): Mangle trailing requires-clause. (write_name): Pass parms to write_template_args. (write_template_param_decl): Factor out from... (write_closure_template_head): ...here. (write_template_args): Mangle non-natural parms and requires-clause. (write_expression): Handle REQUIRES_EXPR. include/ChangeLog: * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CONSTRAINTS. libiberty/ChangeLog: * cp-demangle.c (d_make_comp): Handle DEMANGLE_COMPONENT_CONSTRAINTS. (d_count_templates_scopes): Likewise. (d_print_comp_inner): Likewise. (d_maybe_constraints): New. (d_encoding, d_template_args_1): Call it. (d_parmlist): Handle 'Q'. * testsuite/demangle-expected: Add some constraint tests. libstdc++-v3/ChangeLog: * include/std/bit: Avoid builtins in requires-clauses. * include/std/variant: Likewise. gcc/testsuite/ChangeLog: * g++.dg/abi/mangle10.C: Disable compat aliases. * g++.dg/abi/mangle52.C: Specify ABI 18. * g++.dg/cpp2a/class-deduction-alias3.C * g++.dg/cpp2a/class-deduction-alias8.C: Avoid builtins in requires-clauses. * g++.dg/abi/mangle-concepts1.C: New test. * g++.dg/abi/mangle-ttp1.C: New test.
…er gcc versions. This brings in the following commits: commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Dec 5 23:32:19 2023 +0100 libiberty: Fix build with GCC < 7 Tobias reported on IRC that the linker fails to build with GCC 4.8.5. In configure I've tried to use everything actually used in the sha1.c x86 hw implementation, but unfortunately I forgot about implicit function declarations. GCC before 7 did have <cpuid.h> header and bit_SHA define and __get_cpuid function defined inline, but it didn't define __get_cpuid_count, which compiled fine (and the configure test is intentionally compile time only) due to implicit function declaration, but then failed to link when linking the linker, because __get_cpuid_count wasn't defined anywhere. The following patch fixes that by using what autoconf uses in AC_CHECK_DECL to make sure the functions are declared. commit 691858d279335eeeeed3afafdf872b1c5f8f4201 Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> Date: Tue Dec 5 11:04:06 2023 +0100 libiberty: Fix pex_unix_wait return type The recent warning patches broke Solaris bootstrap: /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} [-Wincompatible-pointer-types] 326 | pex_unix_wait, | ^~~~~~~~~~~~~ /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait') While pex_funcs.wait expects a function returning pid_t, pex_unix_wait currently returns int. However, on Solaris pid_t is long for 32-bit, but int for 64-bit. This patches fixes this by having pex_unix_wait return pid_t as expected, and like every other variant already does. Bootstrapped without regressions on i386-pc-solaris2.11, sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and x86_64-apple-darwin23.1.0. commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 Author: Jason Merrill <jason@redhat.com> Date: Mon Sep 25 10:15:02 2023 +0100 c++: mangle function template constraints Per itanium-cxx-abi/cxx-abi#24 and itanium-cxx-abi/cxx-abi#166 We need to mangle constraints to be able to distinguish between function templates that only differ in constraints. From the latter link, we want to use the template parameter mangling previously specified for lambdas to also make explicit the form of a template parameter where the argument is not a "natural" fit for it, such as when the parameter is constrained or deduced. I'm concerned about how the latter link changes the mangling for some C++98 and C++11 patterns, so I've limited template_parm_natural_p to avoid two cases found by running the testsuite with -Wabi forced on: template <class T, T V> T f() { return V; } int main() { return f<int,42>(); } template <int i> int max() { return i; } template <int i, int j, int... rest> int max() { int sub = max<j, rest...>(); return i > sub ? i : sub; } int main() { return max<1,2,3>(); } A third C++11 pattern is changed by this patch: template <template <typename...> class TT, typename... Ts> TT<Ts...> f(); template <typename> struct A { }; int main() { f<A,int>(); } I aim to resolve these with the ABI committee before GCC 14.1. We also need to resolve itanium-cxx-abi/cxx-abi#38 (mangling references to dependent template-ids where the name is fully resolved) as references to concepts in std:: will consistently run into this area. This is why mangle-concepts1.C only refers to concepts in the global namespace so far. The library changes are to avoid trying to mangle builtins, which fails. Demangler support and test coverage is not complete yet. commit f2c52c0dfde581461959b0e2b423ad106aadf179 Author: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> Date: Thu Nov 30 10:06:23 2023 +0100 libiberty: Disable hwcaps for sha1.o This patch commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Nov 28 13:14:05 2023 +0100 libiberty: Use x86 HW optimized sha1 broke Solaris/x86 bootstrap with the native as: libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ] gccgo: fatal error: Killed signal terminated program go1 As is already done in a couple of other similar cases, this patches disables hwcaps support for libiberty. Initially, this didn't work because config/hwcaps.m4 uses target_os, but didn't ensure it is defined. Tested on i386-pc-solaris2.11 with as and gas. commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Nov 28 13:14:05 2023 +0100 libiberty: Use x86 HW optimized sha1 Nick has approved this patch (+ small ld change to use it for --build-id=), so I'm commiting it to GCC as master as well. If anyone from ARM would be willing to implement it similarly with vsha1{cq,mq,pq,h,su0q,su1q}_u32 intrinsics, it could be a useful linker speedup on those hosts as well, the intent in sha1.c was that sha1_hw_process_bytes, sha1_hw_process_block functions would be defined whenever defined (HAVE_X86_SHA1_HW_SUPPORT) || defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) but the body of sha1_hw_process_block and sha1_choose_process_bytes would then have #elif defined (HAVE_WHATEVERELSE_SHA1_HW_SUPPORT) for the other arch support, similarly for any target attributes on sha1_hw_process_block if needed. commit 01bc30b222a9d2ff0269325d9e367f8f1fcef942 Author: Mark Wielaard <mjw@redhat.com> Date: Wed Nov 15 20:27:08 2023 +0100 Regenerate libiberty/aclocal.m4 with aclocal 1.15.1 There is a new buildbot check that all autotool files are generated with the correct versions (automake 1.15.1 and autoconf 2.69). https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen Correct one file that was generated with the wrong version. commit 879cf9ff45d94065d89e24b71c6b27c7076ac518 Author: Brendan Shanks <bshanks@codeweavers.com> Date: Thu Nov 9 21:01:07 2023 -0700 [PATCH v3] libiberty: Use posix_spawn in pex-unix when available. Hi, This patch implements pex_unix_exec_child using posix_spawn when available. This should especially benefit recent macOS (where vfork just calls fork), but should have equivalent or faster performance on all platforms. In addition, the implementation is substantially simpler than the vfork+exec code path. Tested on x86_64-linux. v2: Fix error handling (previously the function would be run twice in case of error), and don't use a macro that changes control flow. v3: Match file style for error-handling blocks, don't close in/out/errdes on error, and check close() for errors. commit 810bcc00156cefce7ad40fc9d8de6e43c3a04450 Author: Jason Merrill <jason@redhat.com> Date: Thu Aug 17 11:36:23 2023 -0400 c++: constrained hidden friends [PR109751] r13-4035 avoided a problem with overloading of constrained hidden friends by checking satisfaction, but checking satisfaction early is inconsistent with the usual late checking and can lead to hard errors, so let's not do that after all. We were wrongly treating the different instantiations of the same friend template as the same function because maybe_substitute_reqs_for was failing to actually substitute in the case of a non-template friend. But we don't actually need to do the substitution anyway, because [temp.friend] says that such a friend can't be the same as any other declaration. After fixing that, instead of a redefinition error we got an ambiguous overload error, fixed by allowing constrained hidden friends to coexist until overload resolution, at which point they probably won't be in the same ADL overload set anyway. And we avoid mangling collisions by following the proposed mangling for these friends as a member function with an extra 'F' before the name. I demangle this by just adding [friend] to the name of the function because it's not feasible to reconstruct the actual scope of the function since the mangling ABI doesn't distinguish between class and namespace scopes. PR c++/109751
Per itanium-cxx-abi/cxx-abi#24 and itanium-cxx-abi/cxx-abi#166 We need to mangle constraints to be able to distinguish between function templates that only differ in constraints. From the latter link, we want to use the template parameter mangling previously specified for lambdas to also make explicit the form of a template parameter where the argument is not a "natural" fit for it, such as when the parameter is constrained or deduced. I'm concerned about how the latter link changes the mangling for some C++98 and C++11 patterns, so I've limited template_parm_natural_p to avoid two cases found by running the testsuite with -Wabi forced on: template <class T, T V> T f() { return V; } int main() { return f<int,42>(); } template <int i> int max() { return i; } template <int i, int j, int... rest> int max() { int sub = max<j, rest...>(); return i > sub ? i : sub; } int main() { return max<1,2,3>(); } A third C++11 pattern is changed by this patch: template <template <typename...> class TT, typename... Ts> TT<Ts...> f(); template <typename> struct A { }; int main() { f<A,int>(); } I aim to resolve these with the ABI committee before GCC 14.1. We also need to resolve itanium-cxx-abi/cxx-abi#38 (mangling references to dependent template-ids where the name is fully resolved) as references to concepts in std:: will consistently run into this area. This is why mangle-concepts1.C only refers to concepts in the global namespace so far. The library changes are to avoid trying to mangle builtins, which fails. Demangler support and test coverage is not complete yet. gcc/cp/ChangeLog: * cp-tree.h (TEMPLATE_ARGS_TYPE_CONSTRAINT_P): New. (get_concept_check_template): Declare. * constraint.cc (combine_constraint_expressions) (finish_shorthand_constraint): Use UNKNOWN_LOCATION. * pt.cc (convert_generic_types_to_packs): Likewise. * mangle.cc (write_constraint_expression) (write_tparms_constraints, write_type_constraint) (template_parm_natural_p, write_requirement) (write_requires_expr): New. (write_encoding): Mangle trailing requires-clause. (write_name): Pass parms to write_template_args. (write_template_param_decl): Factor out from... (write_closure_template_head): ...here. (write_template_args): Mangle non-natural parms and requires-clause. (write_expression): Handle REQUIRES_EXPR. include/ChangeLog: * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CONSTRAINTS. libiberty/ChangeLog: * cp-demangle.c (d_make_comp): Handle DEMANGLE_COMPONENT_CONSTRAINTS. (d_count_templates_scopes): Likewise. (d_print_comp_inner): Likewise. (d_maybe_constraints): New. (d_encoding, d_template_args_1): Call it. (d_parmlist): Handle 'Q'. * testsuite/demangle-expected: Add some constraint tests. libstdc++-v3/ChangeLog: * include/std/bit: Avoid builtins in requires-clauses. * include/std/variant: Likewise. gcc/testsuite/ChangeLog: * g++.dg/abi/mangle10.C: Disable compat aliases. * g++.dg/abi/mangle52.C: Specify ABI 18. * g++.dg/cpp2a/class-deduction-alias3.C * g++.dg/cpp2a/class-deduction-alias8.C: Avoid builtins in requires-clauses. * g++.dg/abi/mangle-concepts1.C: New test. * g++.dg/abi/mangle-ttp1.C: New test.
Per itanium-cxx-abi/cxx-abi#24 and itanium-cxx-abi/cxx-abi#166 We need to mangle constraints to be able to distinguish between function templates that only differ in constraints. From the latter link, we want to use the template parameter mangling previously specified for lambdas to also make explicit the form of a template parameter where the argument is not a "natural" fit for it, such as when the parameter is constrained or deduced. I'm concerned about how the latter link changes the mangling for some C++98 and C++11 patterns, so I've limited template_parm_natural_p to avoid two cases found by running the testsuite with -Wabi forced on: template <class T, T V> T f() { return V; } int main() { return f<int,42>(); } template <int i> int max() { return i; } template <int i, int j, int... rest> int max() { int sub = max<j, rest...>(); return i > sub ? i : sub; } int main() { return max<1,2,3>(); } A third C++11 pattern is changed by this patch: template <template <typename...> class TT, typename... Ts> TT<Ts...> f(); template <typename> struct A { }; int main() { f<A,int>(); } I aim to resolve these with the ABI committee before GCC 14.1. We also need to resolve itanium-cxx-abi/cxx-abi#38 (mangling references to dependent template-ids where the name is fully resolved) as references to concepts in std:: will consistently run into this area. This is why mangle-concepts1.C only refers to concepts in the global namespace so far. The library changes are to avoid trying to mangle builtins, which fails. Demangler support and test coverage is not complete yet. gcc/cp/ChangeLog: * cp-tree.h (TEMPLATE_ARGS_TYPE_CONSTRAINT_P): New. (get_concept_check_template): Declare. * constraint.cc (combine_constraint_expressions) (finish_shorthand_constraint): Use UNKNOWN_LOCATION. * pt.cc (convert_generic_types_to_packs): Likewise. * mangle.cc (write_constraint_expression) (write_tparms_constraints, write_type_constraint) (template_parm_natural_p, write_requirement) (write_requires_expr): New. (write_encoding): Mangle trailing requires-clause. (write_name): Pass parms to write_template_args. (write_template_param_decl): Factor out from... (write_closure_template_head): ...here. (write_template_args): Mangle non-natural parms and requires-clause. (write_expression): Handle REQUIRES_EXPR. include/ChangeLog: * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CONSTRAINTS. libiberty/ChangeLog: * cp-demangle.c (d_make_comp): Handle DEMANGLE_COMPONENT_CONSTRAINTS. (d_count_templates_scopes): Likewise. (d_print_comp_inner): Likewise. (d_maybe_constraints): New. (d_encoding, d_template_args_1): Call it. (d_parmlist): Handle 'Q'. * testsuite/demangle-expected: Add some constraint tests. libstdc++-v3/ChangeLog: * include/std/bit: Avoid builtins in requires-clauses. * include/std/variant: Likewise. gcc/testsuite/ChangeLog: * g++.dg/abi/mangle10.C: Disable compat aliases. * g++.dg/abi/mangle52.C: Specify ABI 18. * g++.dg/cpp2a/class-deduction-alias3.C * g++.dg/cpp2a/class-deduction-alias8.C: Avoid builtins in requires-clauses. * g++.dg/abi/mangle-concepts1.C: New test. * g++.dg/abi/mangle-ttp1.C: New test.
I would really like to resolve this issue at the same time as adding constraint mangling, since constraints will have a lot of references to resolved names (of concepts). Any thoughts about my last proposal? |
Per itanium-cxx-abi/cxx-abi#24 and itanium-cxx-abi/cxx-abi#166 We need to mangle constraints to be able to distinguish between function templates that only differ in constraints. From the latter link, we want to use the template parameter mangling previously specified for lambdas to also make explicit the form of a template parameter where the argument is not a "natural" fit for it, such as when the parameter is constrained or deduced. I'm concerned about how the latter link changes the mangling for some C++98 and C++11 patterns, so I've limited template_parm_natural_p to avoid two cases found by running the testsuite with -Wabi forced on: template <class T, T V> T f() { return V; } int main() { return f<int,42>(); } template <int i> int max() { return i; } template <int i, int j, int... rest> int max() { int sub = max<j, rest...>(); return i > sub ? i : sub; } int main() { return max<1,2,3>(); } A third C++11 pattern is changed by this patch: template <template <typename...> class TT, typename... Ts> TT<Ts...> f(); template <typename> struct A { }; int main() { f<A,int>(); } I aim to resolve these with the ABI committee before GCC 14.1. We also need to resolve itanium-cxx-abi/cxx-abi#38 (mangling references to dependent template-ids where the name is fully resolved) as references to concepts in std:: will consistently run into this area. This is why mangle-concepts1.C only refers to concepts in the global namespace so far. The library changes are to avoid trying to mangle builtins, which fails. Demangler support and test coverage is not complete yet. gcc/cp/ChangeLog: * cp-tree.h (TEMPLATE_ARGS_TYPE_CONSTRAINT_P): New. (get_concept_check_template): Declare. * constraint.cc (combine_constraint_expressions) (finish_shorthand_constraint): Use UNKNOWN_LOCATION. * pt.cc (convert_generic_types_to_packs): Likewise. * mangle.cc (write_constraint_expression) (write_tparms_constraints, write_type_constraint) (template_parm_natural_p, write_requirement) (write_requires_expr): New. (write_encoding): Mangle trailing requires-clause. (write_name): Pass parms to write_template_args. (write_template_param_decl): Factor out from... (write_closure_template_head): ...here. (write_template_args): Mangle non-natural parms and requires-clause. (write_expression): Handle REQUIRES_EXPR. include/ChangeLog: * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CONSTRAINTS. libiberty/ChangeLog: * cp-demangle.c (d_make_comp): Handle DEMANGLE_COMPONENT_CONSTRAINTS. (d_count_templates_scopes): Likewise. (d_print_comp_inner): Likewise. (d_maybe_constraints): New. (d_encoding, d_template_args_1): Call it. (d_parmlist): Handle 'Q'. * testsuite/demangle-expected: Add some constraint tests. libstdc++-v3/ChangeLog: * include/std/bit: Avoid builtins in requires-clauses. * include/std/variant: Likewise. gcc/testsuite/ChangeLog: * g++.dg/abi/mangle10.C: Disable compat aliases. * g++.dg/abi/mangle52.C: Specify ABI 18. * g++.dg/cpp2a/class-deduction-alias3.C * g++.dg/cpp2a/class-deduction-alias8.C: Avoid builtins in requires-clauses. * g++.dg/abi/mangle-concepts1.C: New test. * g++.dg/abi/mangle-ttp1.C: New test.
Previously: http://sourcerytools.com/pipermail/cxx-abi-dev/2015-October/002867.html
I think the problem here does not only affect substitutable prefixes for unresolved-names. Clang and GCC also disagree about how to mangle this:
... where GCC gives
_Z3argIfEN9enable_ifIXsrN1Y7is_sameIT_fEE5valueEfE4typeES3_
(which doesn't match the grammar in the ABI), and Clang gives_Z3argIfEN9enable_ifIXsr7is_sameIT_fEE5valueEfE4typeES1_
(which can collide with a different function in a different TU).I think GCC's approach is closer to being the right one. If we can resolve an initial portion of an <unresolved-name>, we should emit the fully-qualified path to the resolved component. Though there are some other open questions here: is the partially-resolved name substitutable? (Do we get
S1_
orS3_
at the end of the mangling?) Does it receive a leadingN
, per GCC's mangling, or no leadingN
, per Clang's mangling / the ABI?The text was updated successfully, but these errors were encountered: