Started between 20220925 and 20221009 : $ cat z1.cc template<class> void f() { auto a = [] (auto x) static { return x; }; } template void f<int>(); $ g++-13-20230122 -c z1.cc -std=c++23 z1.cc: In instantiation of 'void f() [with <template-parameter-1-1> = int]': z1.cc:5:22: required from here z1.cc:3:12: internal compiler error: in start_preparsed_function, at cp/decl.cc:17281 3 | auto a = [] (auto x) static { return x; }; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0x8f97a4 start_preparsed_function(tree_node*, tree_node*, int) ../../gcc/cp/decl.cc:17280 0x9740a4 start_lambda_function(tree_node*, tree_node*) ../../gcc/cp/lambda.cc:1671 0xac5400 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.cc:20056 0xa8bc86 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.cc:21604 0xa94330 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.cc:19764 0xa9b00e tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.cc:18711 0xa9b00e tsubst_init ../../gcc/cp/pt.cc:17007 0xa972ae tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.cc:18910 0xa9241e tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.cc:18725 0xa9127f tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.cc:19105 0xa9d6c6 tsubst_expr(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.cc:18711 0xa9d6c6 instantiate_body ../../gcc/cp/pt.cc:26702 0xa9ec21 instantiate_decl(tree_node*, bool, bool) ../../gcc/cp/pt.cc:26992 0xadc5db instantiate_pending_templates(int) ../../gcc/cp/pt.cc:27070 0x939c39 c_parse_final_cleanups() ../../gcc/cp/decl2.cc:4953 0xbf0ac0 c_common_parse_file() ../../gcc/c-family/c-opts.cc:1266
This is valid code in C++23. Most likely the ICE started when static operator() support (for C++23) came in via r13-2892-g303976a6076f28 .
Indeed, also started with r13-2892-g303976a6076f283935470
The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:39ade88fa1632c659c5c4ed065fa2b62d16a8670 commit r13-5334-g39ade88fa1632c659c5c4ed065fa2b62d16a8670 Author: Jason Merrill <jason@redhat.com> Date: Tue Jan 24 15:29:35 2023 -0500 c++: static lambda in template [PR108526] tsubst_lambda_expr uses build_memfn_type to build a METHOD_TYPE for the new lamba op(). This is not what we want for a C++23 static op(), but since we also use that METHOD_TYPE to communicate the closure type down to tsubst_function_decl, let's wait and turn it back at that point. PR c++/108526 gcc/cp/ChangeLog: * pt.cc (tsubst_function_decl): Handle static lambda. gcc/testsuite/ChangeLog: * g++.dg/cpp23/static-operator-call5.C: New test.
Fixed.
The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>: https://gcc.gnu.org/g:4f181f9c7ee3efc509d185fdfda33be9018f1611 commit r13-6533-g4f181f9c7ee3efc509d185fdfda33be9018f1611 Author: Jason Merrill <jason@redhat.com> Date: Mon Mar 6 21:36:28 2023 -0500 c++: static lambda tsubst [PR108526] A missed piece of the patch for static operator(): in tsubst_function_decl, we don't want to replace the first parameter with a new closure pointer if operator() is static. PR c++/108526 PR c++/106651 gcc/cp/ChangeLog: * pt.cc (tsubst_function_decl): Don't replace the closure parameter if DECL_STATIC_FUNCTION_P. gcc/testsuite/ChangeLog: * g++.dg/cpp23/static-operator-call5.C: Pass -g.