The code below gets ICE with gcc9.2 and gcc7.5 (the versions I have immediately available to test with). The error message is: internal compiler error: unexpected expression '(bool)(true)' of kind cast_expr To test: g++ -c -std=c++11 ice-expr-sfinae.cpp Strangely, using a namespace scope function template instead of a static member function template works fine. To demonstrate that, compile with -DTRIGGER_ICE=0. ----- ice-expr-sfinae.cpp ----- #include <type_traits> #ifndef TRIGGER_ICE #define TRIGGER_ICE 1 #endif #if TRIGGER_ICE struct slip { template<bool C> static constexpr bool condition() { return C; } }; template<typename std::enable_if<slip::condition<bool(true)>(), int>::type = 0> static bool dispatch() { return true; } bool test() { return dispatch(); } #else // No ICE if the condition function is at namespace scope. template<bool C> static constexpr bool noslip_condition() { return C; } template<typename std::enable_if<noslip_condition<bool(true)>(), int>::type = 0> static bool dispatch() { return true; } bool test() { return dispatch(); } #endif ----- end of file -----
This was labeled as "ice-on-invalid-code". Am I missing something? I don't see anything invalid here.
(In reply to kab from comment #1) > This was labeled as "ice-on-invalid-code". Am I missing something? I don't > see anything invalid here. I just now adjusted the label to be "ice-on-valid-code" instead. This seems to be a regression relative to GCC 4.8, which compiles the testcase successfully (with -std=c++11). We began ICEing on the testcase starting with r0-122271. Here is a reduced testcase: template <int> struct a { }; struct c { template <int d> static constexpr bool condition() { return d; } }; template<typename> void foo() { using A = a<c::condition<bool(true)>()>; } void bar() { foo<int>(); }
The reason we fail to compile the testcase when 'condition' is at class scope instead of at namespace scope is because in the former case, the template argument 'c::condition<bool(true)>' is a CALL_EXPR to a BASELINK, and when doing instantiate_non_dependent_expr_internal on this CALL_EXPR, we don't semantically process the template argument 'bool(true)' within BASELINK because we never call tsubst_baselink because tsubst_copy exits early when args is NULL_TREE. We don't have this problem in the latter case where 'condition' is at namespace scope, because then the template argument 'condition<bool(true)>' is a CALL_EXPR to a TEMPLATE_ID_EXPR, and TEMPLATE_ID_EXPRs are handled directly from tsubst_copy_and_build which doesn't do an early exit when args is NULL_TREE. A potential untested fix therefore is to also handle BASELINK directly from tsubst_copy_and_build: diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index d7f61289621..e15fca54823 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -19472,6 +19472,11 @@ tsubst_copy_and_build (tree t, case SCOPE_REF: RETURN (tsubst_qualified_id (t, args, complain, in_decl, /*done=*/true, /*address_p=*/false)); + + case BASELINK: + RETURN (tsubst_baselink (t, current_nonlambda_class_type (), + args, complain, in_decl)); + case ARRAY_REF: op1 = tsubst_non_call_postfix_expression (TREE_OPERAND (t, 0), args, complain, in_decl); Ideally we might want two versions of tsubst_baselink, one that does template argument substitution and another than additionally performs semantic processing?
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:5bd7afb71fca3a5a6e9f8586d86903bae1849193 commit r11-7345-g5bd7afb71fca3a5a6e9f8586d86903bae1849193 Author: Patrick Palka <ppalka@redhat.com> Date: Tue Feb 23 09:40:09 2021 -0500 c++: Fix folding of non-dependent BASELINKs [PR95468] Here, the problem ultimately seems to be that tsubst_copy_and_build, when called with empty args as we do during non-dependent expression folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy which then immediately exits early due to the empty args. This means that the CAST_EXPR int(1) in the BASELINK A::condition<int(1)> never gets folded (as part of folding of the overall CALL_EXPR), which later causes us to crash when performing overload resolution of the rebuilt CALL_EXPR (which is still in terms of this templated BASELINK). This doesn't happen when condition() is a namespace-scope function because then condition<int(1)> is represented by a TEMPLATE_ID_EXPR rather than by a BASELINK, which does get handled directly from tsubst_copy_and_build. This patch fixes this issue by having tsubst_copy_and_build handle BASELINK directly rather than delegating to tsubst_copy, so that it processes BASELINKs even when args is empty. gcc/cp/ChangeLog: PR c++/95468 * pt.c (tsubst_copy_and_build) <case BASELINK>: New case, copied over from tsubst_copy. gcc/testsuite/ChangeLog: PR c++/95468 * g++.dg/template/non-dependent15.C: New test.
Fixed for GCC 11 so far.
The releases/gcc-10 branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:78e6c55b0d0d2d49f489c581cf8d5a8125b28563 commit r10-9636-g78e6c55b0d0d2d49f489c581cf8d5a8125b28563 Author: Patrick Palka <ppalka@redhat.com> Date: Tue Feb 23 09:40:09 2021 -0500 c++: Fix folding of non-dependent BASELINKs [PR95468] Here, the problem ultimately seems to be that tsubst_copy_and_build, when called with empty args as we do during non-dependent expression folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy which then immediately exits early due to the empty args. This means that the CAST_EXPR int(1) in the BASELINK A::condition<int(1)> never gets folded (as part of folding of the overall CALL_EXPR), which later causes us to crash when performing overload resolution of the rebuilt CALL_EXPR (which is still in terms of this templated BASELINK). This doesn't happen when condition() is a namespace-scope function because then condition<int(1)> is represented by a TEMPLATE_ID_EXPR rather than by a BASELINK, which does get handled directly from tsubst_copy_and_build. This patch fixes this issue by having tsubst_copy_and_build handle BASELINK directly rather than delegating to tsubst_copy, so that it processes BASELINKs even when args is empty. gcc/cp/ChangeLog: PR c++/95468 * pt.c (tsubst_copy_and_build) <case BASELINK>: New case, copied over from tsubst_copy. gcc/testsuite/ChangeLog: PR c++/95468 * g++.dg/template/non-dependent15.C: New test. (cherry picked from commit 5bd7afb71fca3a5a6e9f8586d86903bae1849193)
The releases/gcc-9 branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:1b265d910f27743dc3ea8e4fde6c292df220fb9f commit r9-9456-g1b265d910f27743dc3ea8e4fde6c292df220fb9f Author: Patrick Palka <ppalka@redhat.com> Date: Tue Feb 23 09:40:09 2021 -0500 c++: Fix folding of non-dependent BASELINKs [PR95468] Here, the problem ultimately seems to be that tsubst_copy_and_build, when called with empty args as we do during non-dependent expression folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy which then immediately exits early due to the empty args. This means that the CAST_EXPR int(1) in the BASELINK A::condition<int(1)> never gets folded (as part of folding of the overall CALL_EXPR), which later causes us to crash when performing overload resolution of the rebuilt CALL_EXPR (which is still in terms of this templated BASELINK). This doesn't happen when condition() is a namespace-scope function because then condition<int(1)> is represented by a TEMPLATE_ID_EXPR rather than by a BASELINK, which does get handled directly from tsubst_copy_and_build. This patch fixes this issue by having tsubst_copy_and_build handle BASELINK directly rather than delegating to tsubst_copy, so that it processes BASELINKs even when args is empty. gcc/cp/ChangeLog: PR c++/95468 * pt.c (tsubst_copy_and_build) <case BASELINK>: New case, copied over from tsubst_copy. gcc/testsuite/ChangeLog: PR c++/95468 * g++.dg/template/non-dependent15.C: New test. (cherry picked from commit 5bd7afb71fca3a5a6e9f8586d86903bae1849193)
The GCC 8 branch is being closed, fixed in GCC 9.4.