[{"id":3683022,"web_url":"http://patchwork.ozlabs.org/comment/3683022/","msgid":"","list_archive_url":null,"date":"2026-04-27T22:03:14","subject":"Re: [PATCH v4] c++/reflection: ICE on member function template\n splicing [PR124794]","submitter":{"id":4337,"url":"http://patchwork.ozlabs.org/api/people/4337/","name":"Jason Merrill","email":"jason@redhat.com"},"content":"On 4/27/26 2:14 PM, feedable wrote:\n>>>>>>> + else if (BASELINK_P (expr))\n>>>>>>> + expr = build_baselink (access_path, BASELINK_BINFO (expr),\n>>>>>\n>>>>> Extra space before =. Also I guess BASELINK_ACCESS_BINFO instead of\n>>>>> BASELINK_BINFO?\n>>>>\n>>>> We want to use access_path (relative to the actual object_type) in place of\n>>>> BASELINK_ACCESS_BINFO, but indeed the access path should be the second\n>>>> argument rather than the first in both this call and the existing one.\n>>>\n>>> If I understand correctly, access_path is the endpoint of the search, so it\n>>> should go into BASELINK_BINFO, and it's the object type that should go\n>>> into BASELINK_ACCESS_BINFO (in both cases, actually), since it's the\n>>> place where we started the search.\n>>\n>> Ah, true.\n> \n> Apparently, the start would actually correspond to the time when we got\n> the reflection in the first place (as we are essentially performing\n> x.C::m, but with C::m being spliced); so obtaining the access binfo from the\n> reflection here is correct.\n\nI think you were right before; the reflection of a member does not \ninclude any information about how it was produced, whether from ^^ \ndirectly or otherwise. And normally BASELINK_ACCESS_BINFO needs to \nrepresent either the object type or a base thereof.\n\nSo using TYPE_BINFO (object_type) as in v3 makes sense. Of course we're \nsuppressing access checking anyway so it doesn't much matter, but better \nto be correct if it isn't a burden.\n\n>>>>>>> It might also make sense to move the template arguments\n>>>>>>> inside the SPLICE_EXPR so that we have them available in\n>>>>>>> tsubst_splice_expr. This seems reasonable since they are\n>>>>>>> part of the splice*specifier.\n>>>>>>\n>>>>>> Another option would be to detect a TEMPLATE_ID_EXPR where the\n>>>>>> template part is a SPLICE_EXPR, and forward that to\n>>>>>> tsubst_splice_expr as a TEMPLATE_ID_EXPR, instead of creating\n>>>>>> another node type or expanding the SPLICE_EXPR.\n>>>>>\n>>>>> Sure, that would also work.\n>>\n>> I'd prefer this: tsubst already does something like this for\n>> a TEMPLATE_ID_EXPR with SPLICE_EXPR.\n> \n> The case of tsubst is a little different, as I understand it: the\n> structure there is basically splice-scope(template-id(splice-expr,\n> args)); and only the splice-expr part will be in the tsubst_splice_expr,\n> and that will expand into a type, on which no processing has to be done.\n> But tsubst_expr here would forward the template-id itself, and handle\n> that within.\n> \n> -- >8 --\n> \n> cp_parser_splice_expression is stripping BASELINKs before resolving the expr;\n> checks if the result is a BASELINK after that (by which point it never is).\n> To fix it, stop stripping the BASELINK, add handling to check_splice_expr\n> instead.\n> \n> In cp_parser_splice_specifier, the additional template param parsing fails to\n> detect that the reflection is a template if it's wrapped in a BASELINKs, and\n> decides not to parse the splice-specialization-specifier if the 'template'\n> keyword is missing. Grab the data from the reflection instead.\n> \n> During template isntantiation, we blindly substitute the template part of a\n> TEMPLATE_ID_EXPR, even if it's a SPLICE_EXPR. This, in turn, substitutes the\n> SPLICE_EXPR as-if it had no template arguments and finishes up the expression,\n> which interferes with later processing by TEMPLATE_ID_EXPR.\n> To fix, we defer such TEMPLATE_ID_EXPRs to tsubst_splice_expr, which itself\n> performs the substitution of a TEMPLATE_ID_EXPR and finishes up the expression.\n> \n> \tPR c++/124794\n> \n> gcc/cp/ChangeLog:\n> \n> \t* parser.cc (cp_parser_splice_specifier): Do not strip BASELINKs\n\nChange descriptions should end in a period.\n\n> \t(cp_parser_splice_expression): Add parsing for member function template\n> \tspecializations without the \"template\" keyword\n> \t* pt.cc (tsubst_splice_expr): Handle TEMPLATE_ID_EXPR where the template\n> \tpart is a SPLICE_EXPR\n\nIt looks like this change still needs to handle the dependent_splice_p \ncase; currently it will throw away the template args.\n\n> \t(tsubst_expr): Defer to tsubst_splice_expr when thetemplate part of\n> \tTEMPLATE_ID_EXPR is a SPLICE_EXPR\n> \t* reflect.cc (check_splice_expr): Add handling for BASELINKs\n\nI still think MAYBE_BASELINK_FUNCTIONS or maybe_get_first_fn at the top \nof check_splice_expr can replace changing multiple places in the \nfunction. Nothing in this function is interested in a BASELINK.\n\n> gcc/testsuite/ChangeLog:\n> \n> \t* g++.dg/reflect/member19.C: Enable tests.\n> \t* g++.dg/reflect/splice13.C: New test.\n> ---\n> gcc/cp/parser.cc | 21 ++++++----\n> gcc/cp/pt.cc | 20 +++++++++\n> gcc/cp/reflect.cc | 21 +++++-----\n> gcc/testsuite/g++.dg/reflect/member19.C | 18 ---------\n> gcc/testsuite/g++.dg/reflect/splice13.C | 54 +++++++++++++++++++++++++\n> 5 files changed, 98 insertions(+), 36 deletions(-)\n> create mode 100644 gcc/testsuite/g++.dg/reflect/splice13.C\n> \n> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc\n> index 9f2641f2ab2..4daba6c0260 100644\n> --- a/gcc/cp/parser.cc\n> +++ b/gcc/cp/parser.cc\n> @@ -6179,6 +6179,8 @@ cp_parser_splice_specifier (cp_parser *parser, bool template_p = false,\n> /* Get the reflected operand. */\n> expr = splice (expr);\n> \n> + tree expr_real = maybe_get_first_fn (expr);\n> +\n> /* If the next token is a <, it could be a splice-specialization-specifier.\n> But we need to handle \"[:r:] < 42\" where the < doesn't start a template\n> argument list. [temp.names]/3: A < is interpreted as the delimiter of\n> @@ -6190,30 +6192,34 @@ cp_parser_splice_specifier (cp_parser *parser, bool template_p = false,\n> /* As a courtesy to the user, if there is a < after a template\n> \t name, parse the construct as an s-s-s and warn about the missing\n> \t 'template'; it can't be anything else. */\n> - && (template_p\n> -\t || typename_p\n> -\t || TREE_CODE (OVL_FIRST (expr)) == TEMPLATE_DECL))\n> + && (template_p || typename_p || TREE_CODE (expr_real) == TEMPLATE_DECL))\n> {\n> /* For member access splice-specialization-specifier, try to wrap\n> \t non-dependent splice for function template into a BASELINK so\n> \t that cp_parser_template_id can handle it. */\n> if (object_type\n> -\t && DECL_FUNCTION_TEMPLATE_P (OVL_FIRST (expr))\n> +\t && reflection_function_template_p (expr_real)\n> \t && !dependent_type_p (object_type))\n> \t{\n> -\t tree scope = DECL_CONTEXT (OVL_FIRST (expr));\n> +\t tree scope = DECL_CONTEXT (expr_real);\n> \t if (scope && CLASS_TYPE_P (scope))\n> \t {\n> \t tree access_path = lookup_base (object_type, scope, ba_unique,\n> \t\t\t\t\t NULL, tf_warning_or_error);\n> \t if (access_path == error_mark_node)\n> \t\texpr = error_mark_node;\n> +\t else if (BASELINK_P (expr))\n> +\t\texpr = build_baselink (access_path,\n> +\t\t\t\t BASELINK_ACCESS_BINFO (expr),\n> +\t\t\t\t BASELINK_FUNCTIONS (expr),\n> +\t\t\t\t BASELINK_OPTYPE (expr));\n> \t else\n> \t\texpr\n> \t\t = build_baselink (access_path, TYPE_BINFO (object_type),\n> \t\t\t\t expr,\n> -\t\t\t\t IDENTIFIER_CONV_OP_P (OVL_NAME (expr))\n> -\t\t\t\t ? TREE_TYPE (OVL_NAME (expr)) : NULL_TREE);\n> +\t\t\t\t IDENTIFIER_CONV_OP_P (OVL_NAME (expr_real))\n> +\t\t\t\t ? TREE_TYPE (OVL_NAME (expr_real))\n> +\t\t\t\t : NULL_TREE);\n> \t }\n> \t}\n> /* Let cp_parser_template_id parse the template arguments. */\n> @@ -6316,7 +6322,6 @@ cp_parser_splice_expression (cp_parser *parser, bool template_p,\n> tree t = expr.get_value ();\n> STRIP_ANY_LOCATION_WRAPPER (t);\n> tree unresolved = t;\n> - t = MAYBE_BASELINK_FUNCTIONS (t);\n> t = resolve_nondeduced_context (t, tf_warning_or_error);\n> \n> if (dependent_splice_p (t))\n> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc\n> index 2cf14e2c801..89ddd782005 100644\n> --- a/gcc/cp/pt.cc\n> +++ b/gcc/cp/pt.cc\n> @@ -16926,6 +16926,13 @@ tsubst_splice_scope (tree t, tree args, tsubst_flags_t complain, tree in_decl)\n> static tree\n> tsubst_splice_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)\n> {\n> + tree template_id = NULL_TREE;\n> + if (TREE_CODE (t) == TEMPLATE_ID_EXPR)\n> + {\n> + template_id = copy_node (t);\n\nWe might as well delay this copy until the if (template_id) below, after \nall the error returns.\n\n> + t = TREE_OPERAND (t, 0);\n> + }\n> +\n> tree op = tsubst_expr (TREE_OPERAND (t, 0), args, complain, in_decl);\n> if (op == error_mark_node)\n> return error_mark_node;\n> @@ -16955,6 +16962,16 @@ tsubst_splice_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)\n> \t\t\t (complain & tf_error)))\n> return error_mark_node;\n> \n> + if (template_id)\n> + {\n> + TREE_OPERAND (template_id, 0) = op;\n> + /* Send the unresolved expr, just like we do in\n> +\tcp_parser_splice_expression. */\n> + if (SPLICE_EXPR_MEMBER_ACCESS_P (t))\n> +\treturn template_id;\n\nOn this return you miss substituting the template arguments.\n\nAnd I think this if/return shouldn't be necessary if we pass \ntf_no_name_lookup down as suggested below.\n\n> + op = tsubst_expr (template_id, args, complain, in_decl);\n\nI'm a bit uncomfortable with substituting op a second time, but I guess \nit should be stable.\n\n> + }\n> +\n> if (SPLICE_EXPR_ADDRESS_P (t))\n> {\n> if (BASELINK_P (op))\n> @@ -21450,6 +21467,9 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)\n> \ttree templ = TREE_OPERAND (t, 0);\n> \ttree targs = TREE_OPERAND (t, 1);\n> \n> +\tif (TREE_CODE (templ) == SPLICE_EXPR)\n> +\t return tsubst_splice_expr (t, args, complain, in_decl);\n\nI think we want complain|no_name_lookup_flag here.\n\nJason","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=SDpBdn4i;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=SDpBdn4i","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","server2.sourceware.org;\n arc=none smtp.remote-ip=170.10.133.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g4Hdk1nwDz1xvV\n\tfor ; Tue, 28 Apr 2026 08:03:51 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 7495E4BA798D\n\tfor ; Mon, 27 Apr 2026 22:03:48 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.133.124])\n by sourceware.org (Postfix) with ESMTP id 6502C4BA23E3\n for ; Mon, 27 Apr 2026 22:03:20 +0000 (GMT)","from mail-qk1-f197.google.com (mail-qk1-f197.google.com\n [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-428-uCkZyNufPcqV4x3spWeo9w-1; Mon, 27 Apr 2026 18:03:18 -0400","by mail-qk1-f197.google.com with SMTP id\n af79cd13be357-8e8950b3ee1so2847641585a.3\n for ; Mon, 27 Apr 2026 15:03:18 -0700 (PDT)","from [192.168.50.130]\n (130-44-146-247.s12789.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com.\n [130.44.146.247]) by smtp.gmail.com with ESMTPSA id\n af79cd13be357-8f7c7cd9d6fsm36634785a.30.2026.04.27.15.03.15\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Mon, 27 Apr 2026 15:03:15 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 7495E4BA798D","OpenDKIM Filter v2.11.0 sourceware.org 6502C4BA23E3"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 6502C4BA23E3","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 6502C4BA23E3","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777327400; cv=none;\n b=Coee21EaTx2EvQFf6JDnwiBznk73p53kwjyBuE6KGE0AJjWBAJm3f08ziXFJfSp4Wtcpxgc3oT/1NR+Bf6+kUWBNQyoJNe3YXe5QiMLYm01kkK8myt7kIfKtM36AoDLdh9mM+3jI+fDL6bZD+rUeUEKjoSv1b1AiRWm1Idt0+/8=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777327400; c=relaxed/simple;\n bh=p1l2O3RQik/3GveeotHzYMNqYVjdOMW5vvCYHxmJ874=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=i+Rpb4cmWW8zGXGYBlPZw2zGkFWqAsQwXf2DqbYDtctzvkbd+moysywfulOcC3bORuwHFaa8KGVSiKS1pXGSFOjCNlbkvHYr9wCtVHfCMqNPkPTo6MSpcXtKqSTs1DKTJCgx8fEGB6n1M1m/UG7zLAs5RFnpXVjnFM41vXjJ/1I=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1777327400;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=HbLnqHXUoeudZerLqvZ/Y+AFxOJ9B3hGDrOFgtPGwL0=;\n b=SDpBdn4ikzIPn49Sc9cM9PLx4Yf4nPSGYVOAFBWinsOfxtHKvNrrztvMnsZyVIEc+j7Y+z\n BrhE3Z51MF96xLuz/3esrWHN0ghdFQbEI7FqSyUjlExCOU3hUxj5Q5xUncESvHIlpyhpB1\n Q3+TDpCTt0QST+iIR69gLglyQKve+NE=","X-MC-Unique":"uCkZyNufPcqV4x3spWeo9w-1","X-Mimecast-MFC-AGG-ID":"uCkZyNufPcqV4x3spWeo9w_1777327398","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777327398; x=1777932198;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=HbLnqHXUoeudZerLqvZ/Y+AFxOJ9B3hGDrOFgtPGwL0=;\n b=Lw3apxOFzMIeAIlyyenW5jlcbw/+VSCPcRd6ut8QFXoEJrCc1nMajua/uGUENz9Cfn\n I0UaN62VlaK3sbGhSCSPNylRaWSUmT+lZQUP7TJqeSsbEWWRstAXG/Gg89mt3BWpZA1y\n hi+LQg0cuA4PATCh3sAtZFMcxlp5kRZo6TLu8icNejgwAg0SY2XsLbL0V9uU+kVOfPjP\n J8MsFs2RnqJG+XvQMJjJkelZckD0GgF/UbTdg6Qqb7RTIwTk0EsForeiHCx6+o5KUQzO\n ipY3nD1rMK783chO3SjOHpQt2ugFoNKQazlqoQLOfhJJr8gn5eL21KJiKHz6/EEezYAb\n AwnQ==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8fIb/AVIlH+1vCxO4pPA/Fndf8KDMGgtA9Wv4oRbPERr7m57jMkLBSch6gMrSjM4jusS0dDMLm4PdSmQ==@gcc.gnu.org","X-Gm-Message-State":"AOJu0YxrAcHnRKAdXebKTtsM0cWTsSiTdj339daGEd4PUZQ7heJ65nL5\n gn7lZOln1PMHPhuCgFk9Jui9xzv6jo46lvtd3+k52+nVzDCAKParSwQ4/9UTfsSqo3GApGoztKJ\n Cp1kvBmoyI9oumb0UbnBkDP/sUBEVShz3EYhtd+lCwt3nNxcMLrzegCRgSqY=","X-Gm-Gg":"AeBDietzzQwCzlAXE7QBf8mQh+ZIRsLHadw8rmtC4HfV6azUicdTaMkGQ5FJPypqDYB\n 2lj22wzMoJ/Oi/M8kXI7WFbz+XX0RLyG8RZbrY1bnnkvTuEx3YkZS/W+8kjq6bH1IF/tAdznYv/\n r+Pf2SCfwZoNciziQu1VA0B66wZtY4DvSgmcDZAfXqPslYY8aAkmNIKpXt0z+LA+940aYcfGzvS\n VMfg/WHPiLRj+YnS6euiEDpQLLmQHnh9q+wSpciGpnIy4dNyJ62hLpUPmOWCtKfh/CkrA1k6xA+\n bxUHJ6R/3q8ylE/2uiX/KlLDoQdGfxE9GPV3MIG1GDy79diyjkiHBjvNOdtHNGfogkmfs/DABFR\n i98pw8CTX60aGwlTGQB1oDMVZTU1O9csNzD9jqT5SWzJlbXlE7bdDJoDyMEJYgbzLxdeiSE5ocd\n 7qQhgj1qXcYxZgxnBiQcFZnRet3eHhy8SxaXzwzRiceA==","X-Received":["by 2002:a05:620a:414a:b0:8cf:dd63:fae7 with SMTP id\n af79cd13be357-8f7d8f0e191mr67772585a.34.1777327397541;\n Mon, 27 Apr 2026 15:03:17 -0700 (PDT)","by 2002:a05:620a:414a:b0:8cf:dd63:fae7 with SMTP id\n af79cd13be357-8f7d8f0e191mr67762085a.34.1777327396575;\n Mon, 27 Apr 2026 15:03:16 -0700 (PDT)"],"Message-ID":"","Date":"Mon, 27 Apr 2026 18:03:14 -0400","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v4] c++/reflection: ICE on member function template\n splicing [PR124794]","To":"feedable , gcc-patches@gcc.gnu.org","Cc":"Marek Polacek ","References":"<834e4d1f-cad9-4e33-bde4-cfaf768a8271@gmail.com>\n <20260427182331.85714-1-feedabl3@gmail.com>","From":"Jason Merrill ","In-Reply-To":"<20260427182331.85714-1-feedabl3@gmail.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"uaUG9M9lMdaGhm3DPj6sqNKmQp2bzwbCdf8sjDFAGBI_1777327398","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"7bit","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3683042,"web_url":"http://patchwork.ozlabs.org/comment/3683042/","msgid":"<046bc251-83be-4017-9446-04a7de292cd5@gmail.com>","list_archive_url":null,"date":"2026-04-27T23:14:45","subject":"Re: [PATCH v4] c++/reflection: ICE on member function template\n splicing [PR124794]","submitter":{"id":92146,"url":"http://patchwork.ozlabs.org/api/people/92146/","name":"feedable","email":"feedabl3@gmail.com"},"content":"On 28/04/2026 01:03, Jason Merrill wrote:\n> On 4/27/26 2:14 PM, feedable wrote:\n>>>>>>>> +          else if (BASELINK_P (expr))\n>>>>>>>> +        expr  = build_baselink (access_path, BASELINK_BINFO \n>>>>>>>> (expr),\n>>>>>>\n>>>>>> Extra space before =.  Also I guess BASELINK_ACCESS_BINFO instead of\n>>>>>> BASELINK_BINFO?\n>>>>>\n>>>>> We want to use access_path (relative to the actual object_type) in \n>>>>> place of\n>>>>> BASELINK_ACCESS_BINFO, but indeed the access path should be the \n>>>>> second\n>>>>> argument rather than the first in both this call and the existing \n>>>>> one.\n>>>>\n>>>> If I understand correctly, access_path is the endpoint of the \n>>>> search, so it\n>>>> should go into BASELINK_BINFO, and it's the object type that should go\n>>>> into BASELINK_ACCESS_BINFO (in both cases, actually), since it's the\n>>>> place where we started the search.\n>>>\n>>> Ah, true.\n>>\n>> Apparently, the start would actually correspond to the time when we got\n>> the reflection in the first place (as we are essentially performing\n>> x.C::m, but with C::m being spliced); so obtaining the access binfo \n>> from the\n>> reflection here is correct.\n>\n> I think you were right before; the reflection of a member does not \n> include any information about how it was produced, whether from ^^ \n> directly or otherwise.  And normally BASELINK_ACCESS_BINFO needs to \n> represent either the object type or a base thereof.\nI believe that information is set in \nhttps://forge.sourceware.org/gcc/gcc-TEST/src/commit/c607c686100689e3e68487cd8097c2fbd3904168/gcc/cp/parser.cc#L10181, \nat least for the ^^ case.\n> So using TYPE_BINFO (object_type) as in v3 makes sense.  Of course \n> we're suppressing access checking anyway so it doesn't much matter, \n> but better to be correct if it isn't a burden.\nConsider this case:\n```\nstruct X {};\nstruct Y { template T f(T); };\nauto _ = X{}.[:^^Y::f:](1);\n```\n\nHere, in v3 we build a BASELINK with the start point at X, even though X \nhas nothing to do with Y::f, we couldn't've possibly found Y::F through \nX. This ends up confusing the access checks in \nadjust_result_of_qualified_name_lookup in \ncp_parser_postfix_dot_deref_expression and crashing. In fact, there is a \ntest for this (member13.C) and v3 will fail it, but I somehow didn't \ncatch that at first.\n\n\n>>>>>>>> It might also make sense to move the template arguments\n>>>>>>>> inside the SPLICE_EXPR so that we have them available in\n>>>>>>>> tsubst_splice_expr. This seems reasonable since they are\n>>>>>>>> part of the splice*specifier.\n>>>>>>>\n>>>>>>> Another option would be to detect a TEMPLATE_ID_EXPR where the\n>>>>>>> template part is a SPLICE_EXPR, and forward that to\n>>>>>>> tsubst_splice_expr as a TEMPLATE_ID_EXPR, instead of creating\n>>>>>>> another node type or expanding the SPLICE_EXPR.\n>>>>>>\n>>>>>> Sure, that would also work.\n>>>\n>>> I'd prefer this: tsubst already does something like this for\n>>> a TEMPLATE_ID_EXPR with SPLICE_EXPR.\n>>\n>> The case of tsubst is a little different, as I understand it: the\n>> structure there is basically splice-scope(template-id(splice-expr,\n>> args)); and only the splice-expr part will be in the tsubst_splice_expr,\n>> and that will expand into a type, on which no processing has to be done.\n>> But tsubst_expr here would forward the template-id itself, and handle\n>> that within.\n>>\n>> -- >8 --\n>>\n>> cp_parser_splice_expression is stripping BASELINKs before resolving \n>> the expr;\n>> checks if the result is a BASELINK after that (by which point it \n>> never is).\n>> To fix it, stop stripping the BASELINK, add handling to \n>> check_splice_expr\n>> instead.\n>>\n>> In cp_parser_splice_specifier, the additional template param parsing \n>> fails to\n>> detect that the reflection is a template if it's wrapped in a \n>> BASELINKs, and\n>> decides not to parse the splice-specialization-specifier if the \n>> 'template'\n>> keyword is missing. Grab the data from the reflection instead.\n>>\n>> During template isntantiation, we blindly substitute the template \n>> part of a\n>> TEMPLATE_ID_EXPR, even if it's a SPLICE_EXPR. This, in turn, \n>> substitutes the\n>> SPLICE_EXPR as-if it had no template arguments and finishes up the \n>> expression,\n>> which interferes with later processing by TEMPLATE_ID_EXPR.\n>> To fix, we defer such TEMPLATE_ID_EXPRs to tsubst_splice_expr, which \n>> itself\n>> performs the substitution of a TEMPLATE_ID_EXPR and finishes up the \n>> expression.\n>>\n>>     PR c++/124794\n>>\n>> gcc/cp/ChangeLog:\n>>\n>>     * parser.cc (cp_parser_splice_specifier): Do not strip BASELINKs\n>\n> Change descriptions should end in a period.\n>\n>>     (cp_parser_splice_expression): Add parsing for member function \n>> template\n>>     specializations without the \"template\" keyword\n>>     * pt.cc (tsubst_splice_expr): Handle TEMPLATE_ID_EXPR where the \n>> template\n>>     part is a SPLICE_EXPR\n>\n> It looks like this change still needs to handle the dependent_splice_p \n> case; currently it will throw away the template args.\n>\n>>     (tsubst_expr): Defer to tsubst_splice_expr when thetemplate part of\n>>     TEMPLATE_ID_EXPR is a SPLICE_EXPR\n>>     * reflect.cc (check_splice_expr): Add handling for BASELINKs\n>\n> I still think MAYBE_BASELINK_FUNCTIONS or maybe_get_first_fn at the \n> top of check_splice_expr can replace changing multiple places in the \n> function.  Nothing in this function is interested in a BASELINK.\n>\n>> gcc/testsuite/ChangeLog:\n>>\n>>     * g++.dg/reflect/member19.C: Enable tests.\n>>     * g++.dg/reflect/splice13.C: New test.\n>> ---\n>>   gcc/cp/parser.cc                        | 21 ++++++----\n>>   gcc/cp/pt.cc                            | 20 +++++++++\n>>   gcc/cp/reflect.cc                       | 21 +++++-----\n>>   gcc/testsuite/g++.dg/reflect/member19.C | 18 ---------\n>>   gcc/testsuite/g++.dg/reflect/splice13.C | 54 +++++++++++++++++++++++++\n>>   5 files changed, 98 insertions(+), 36 deletions(-)\n>>   create mode 100644 gcc/testsuite/g++.dg/reflect/splice13.C\n>>\n>> diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc\n>> index 9f2641f2ab2..4daba6c0260 100644\n>> --- a/gcc/cp/parser.cc\n>> +++ b/gcc/cp/parser.cc\n>> @@ -6179,6 +6179,8 @@ cp_parser_splice_specifier (cp_parser *parser, \n>> bool template_p = false,\n>>     /* Get the reflected operand.  */\n>>     expr = splice (expr);\n>>   +  tree expr_real = maybe_get_first_fn (expr);\n>> +\n>>     /* If the next token is a <, it could be a \n>> splice-specialization-specifier.\n>>        But we need to handle \"[:r:] < 42\" where the < doesn't start a \n>> template\n>>        argument list.  [temp.names]/3: A < is interpreted as the \n>> delimiter of\n>> @@ -6190,30 +6192,34 @@ cp_parser_splice_specifier (cp_parser \n>> *parser, bool template_p = false,\n>>         /* As a courtesy to the user, if there is a < after a template\n>>        name, parse the construct as an s-s-s and warn about the missing\n>>        'template'; it can't be anything else.  */\n>> -      && (template_p\n>> -      || typename_p\n>> -      || TREE_CODE (OVL_FIRST (expr)) == TEMPLATE_DECL))\n>> +      && (template_p || typename_p || TREE_CODE (expr_real) == \n>> TEMPLATE_DECL))\n>>       {\n>>         /* For member access splice-specialization-specifier, try to \n>> wrap\n>>        non-dependent splice for function template into a BASELINK so\n>>        that cp_parser_template_id can handle it.  */\n>>         if (object_type\n>> -      && DECL_FUNCTION_TEMPLATE_P (OVL_FIRST (expr))\n>> +      && reflection_function_template_p (expr_real)\n>>         && !dependent_type_p (object_type))\n>>       {\n>> -      tree scope = DECL_CONTEXT (OVL_FIRST (expr));\n>> +      tree scope = DECL_CONTEXT (expr_real);\n>>         if (scope && CLASS_TYPE_P (scope))\n>>           {\n>>             tree access_path = lookup_base (object_type, scope, \n>> ba_unique,\n>>                             NULL, tf_warning_or_error);\n>>             if (access_path == error_mark_node)\n>>           expr = error_mark_node;\n>> +          else if (BASELINK_P (expr))\n>> +        expr = build_baselink (access_path,\n>> +                       BASELINK_ACCESS_BINFO (expr),\n>> +                       BASELINK_FUNCTIONS (expr),\n>> +                       BASELINK_OPTYPE (expr));\n>>             else\n>>           expr\n>>             = build_baselink (access_path, TYPE_BINFO (object_type),\n>>                       expr,\n>> -                    IDENTIFIER_CONV_OP_P (OVL_NAME (expr))\n>> -                    ? TREE_TYPE (OVL_NAME (expr)) : NULL_TREE);\n>> +                    IDENTIFIER_CONV_OP_P (OVL_NAME (expr_real))\n>> +                    ? TREE_TYPE (OVL_NAME (expr_real))\n>> +                    : NULL_TREE);\n>>           }\n>>       }\n>>         /* Let cp_parser_template_id parse the template arguments.  */\n>> @@ -6316,7 +6322,6 @@ cp_parser_splice_expression (cp_parser *parser, \n>> bool template_p,\n>>     tree t = expr.get_value ();\n>>     STRIP_ANY_LOCATION_WRAPPER (t);\n>>     tree unresolved = t;\n>> -  t = MAYBE_BASELINK_FUNCTIONS (t);\n>>     t = resolve_nondeduced_context (t, tf_warning_or_error);\n>>       if (dependent_splice_p (t))\n>> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc\n>> index 2cf14e2c801..89ddd782005 100644\n>> --- a/gcc/cp/pt.cc\n>> +++ b/gcc/cp/pt.cc\n>> @@ -16926,6 +16926,13 @@ tsubst_splice_scope (tree t, tree args, \n>> tsubst_flags_t complain, tree in_decl)\n>>   static tree\n>>   tsubst_splice_expr (tree t, tree args, tsubst_flags_t complain, \n>> tree in_decl)\n>>   {\n>> +  tree template_id = NULL_TREE;\n>> +  if (TREE_CODE (t) == TEMPLATE_ID_EXPR)\n>> +    {\n>> +      template_id = copy_node (t);\n>\n> We might as well delay this copy until the if (template_id) below, \n> after all the error returns.\n\nTrue.\n\n\n>> +      t = TREE_OPERAND (t, 0);\n>> +    }\n>> +\n>>     tree op = tsubst_expr (TREE_OPERAND (t, 0), args, complain, \n>> in_decl);\n>>     if (op == error_mark_node)\n>>       return error_mark_node;\n>> @@ -16955,6 +16962,16 @@ tsubst_splice_expr (tree t, tree args, \n>> tsubst_flags_t complain, tree in_decl)\n>>                    (complain & tf_error)))\n>>       return error_mark_node;\n>>   +  if (template_id)\n>> +    {\n>> +      TREE_OPERAND (template_id, 0) = op;\n>> +      /* Send the unresolved expr, just like we do in\n>> +    cp_parser_splice_expression. */\n>> +      if (SPLICE_EXPR_MEMBER_ACCESS_P (t))\n>> +    return template_id;\n>\n> On this return you miss substituting the template arguments. \n\nTrue.\n\n\n> And I think this if/return shouldn't be necessary if we pass \n> tf_no_name_lookup down as suggested below.\n\nFor the reasons below, we at most can pass that flag for the access \ncase, so within tsubst_splice_expr itself.\n\n\n>\n>> +      op = tsubst_expr (template_id, args, complain, in_decl);\n>\n> I'm a bit uncomfortable with substituting op a second time, but I \n> guess it should be stable.\n\nWe aren't, really. The first substitution only concerns the operand of \nthe splice expr, so that we get the template decl back. The second \nsubstitution is supposed to substitute the template arguments into that \ntemplate, yielding an actual entity.\n\n\n>> +    }\n>> +\n>>     if (SPLICE_EXPR_ADDRESS_P (t))\n>>       {\n>>         if (BASELINK_P (op))\n>> @@ -21450,6 +21467,9 @@ tsubst_expr (tree t, tree args, \n>> tsubst_flags_t complain, tree in_decl)\n>>       tree templ = TREE_OPERAND (t, 0);\n>>       tree targs = TREE_OPERAND (t, 1);\n>>   +    if (TREE_CODE (templ) == SPLICE_EXPR)\n>> +      return tsubst_splice_expr (t, args, complain, in_decl);\n>\n> I think we want complain|no_name_lookup_flag here.\n\nAs I understand the meaning of that flag, we do want that if we don't do \nmember access.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=YosahlTZ;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=YosahlTZ","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=none smtp.remote-ip=209.85.208.54"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g4KDB4NxFz1xvV\n\tfor ; Tue, 28 Apr 2026 09:15:21 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 40D7A4BABF1B\n\tfor ; Mon, 27 Apr 2026 23:15:19 +0000 (GMT)","from mail-ed1-f54.google.com (mail-ed1-f54.google.com\n [209.85.208.54])\n by sourceware.org (Postfix) with ESMTPS id D9D1B4BA23F1\n for ; Mon, 27 Apr 2026 23:14:49 +0000 (GMT)","by mail-ed1-f54.google.com with SMTP id\n 4fb4d7f45d1cf-674a44b84fcso15032000a12.1\n for ; Mon, 27 Apr 2026 16:14:49 -0700 (PDT)","from [10.75.51.213] ([92.60.40.218])\n by smtp.gmail.com with ESMTPSA id\n 4fb4d7f45d1cf-679b68632fesm147635a12.28.2026.04.27.16.14.46\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Mon, 27 Apr 2026 16:14:47 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 40D7A4BABF1B","OpenDKIM Filter v2.11.0 sourceware.org D9D1B4BA23F1"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org D9D1B4BA23F1","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org D9D1B4BA23F1","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777331690; cv=none;\n b=Oz9Ytnqaq1QXrlJyq9uJB3kiVNkXKXEqgNBpUhOi921qaEYWDtF+3a025ex5TfSs5Xkwp4QM/wlyWzi+h/DeMQ6HNpABjm4imMVCKDK0jUJb8IGWP+utdqs6FQXbn9kowCqASP3yi1BKVyrjU18dvpD609MDFD2WnuRy+uKmBbI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777331690; c=relaxed/simple;\n bh=lvyzzpT1jOphsYMeH+mi8eOkHce1pFjWUJp0gPwjJjs=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=O8LduuVPWF/lQbt2Ei3mQnTIB/ff8gQj1m+gVBYbBNNZj3KGvSoSnNZvS5vwiEo7DQFEw0e1Zu23EPUzbEFs0C50mSc0KIxNZoKO+vMQ04kPwP8tmZNGo/9q13HagxNjSNPoI/WUvBwUXacVTm9EuAsvqfq7Q6cjIhhvS6wWN7c=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777331689; x=1777936489; darn=gcc.gnu.org;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :from:to:cc:subject:date:message-id:reply-to;\n bh=MGL4/0gpjrqn+0YQrrx5+N9/x621kbpSQbBxA4vhY4I=;\n b=YosahlTZwAGUlIvyQ9PdyX1+sSYIMtGO+pYKiFykONUP1mbWwcx2ddRC6+Xl0SWRb5\n TZOQYkrZkXIgf+evCUdp03HTVwCRba+6NsfEZh/8z6DNpN0qqp6PQUT5TsjoeVaBTdEw\n luY3zropFzT3uk3M1qBcKAv/lp5JKCGZZyNTavTxO/hlpqNovfudA8Hhu0FOf1CJNtzQ\n qlrMKGdAgODAvUu6z+lw9TFOUYzlbj/bOwdWU56QTr794YcZnJEIazg9ae+NcocqOw2g\n J3YvgoiTPAcSspvo0QFOSeol8Cx8PkDcpgbxmlFhUzzuQhcQZibGoYT3MJGEtUnoB9IG\n I5lg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777331689; x=1777936489;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=MGL4/0gpjrqn+0YQrrx5+N9/x621kbpSQbBxA4vhY4I=;\n b=jldKQjY7vMBWtfLyj79QxF4r/p225tH0gjijV/FfiARxsswoZpqqcKdluNq6YvJa29\n X++Wevz2guLuUYGfzMZlBtNdoH+h6aWapwMHoMTNRXg60L10D/fTzgnAMnh+o72WIKhZ\n v9HlwlRbBJNcQKOiR0To+l2FouTue4MA9/UYPK6mikoq/ZO32psEbmEXpU8pRK0GWSZF\n br0Ua2ryytFMxZeKiDVlDHU7prkTHbv1VqhDs6vbQVwlneYYUKeGEEtQNqvpT/JzVtFL\n 8Vh8Gcg+/d53qA/YHh7OTUrWOxfdvgMUV/Q0cwX0E8+QQwu0vYXVKoJ7vkGobs3O9TD4\n 0UJw==","X-Forwarded-Encrypted":"i=1;\n AFNElJ/sq1jUGXsTwzP3OuPN94aJv8VVoFMuGkL7eKMeNZIkkhknstMF8LvcZfNPWZTmb1kRoSN+6UF6LWs14Q==@gcc.gnu.org","X-Gm-Message-State":"AOJu0Yx6z5wGgpaB5mWTEuwi7apNBkwdyJc/aJrVM0m0TXZUk6I17/gc\n Dhegxhh6F0sGJDRhCcbBilsqNkdeB8ZWuNsdkAhYyWRwUJbT96MxhwIp","X-Gm-Gg":"AeBDietqV7ad6gMjXfkFsE7wYF2jmk3DS/+tH9RJBdral18BfMWjKhKVdf6QQYykCWh\n fXQUpAVQCvLiDENUIuaigTh3BxuA7QZmicoLWbosIDGh+Kb3ZzdzKsnkfP/JMX/76of7QFYy2ju\n JTQkvMBLRtyFZTowI/o2TtCvq/5ShPTAZNrdBTqHkhaMHVBikiu95NeZSm217ktdtQ+nplC11HH\n o7f/hozY4ek4wB2CV5XGt7LdO4tmcsIcYS25Cn/0yhjrGYNSfnTKknwvZddlww7NHq7V0WhLxoc\n dpouZMm2SwWpTZ3c6GIloLTGv8keBPb78UAMn9Tm8T+TH5aDeag/UdqogbdEujxhpQfRocx4xb7\n Di7YjUUq9/95FIy1skv/rHYEiIvNu78/3XoUOlSVMJxU/Vo6Loee1E5+GYkengJWiZlYKj5C69+\n ut6vL9LxI0NkpxSLLuZUXEs7CxnMcHCv+4ZQ==","X-Received":"by 2002:a05:6402:46d5:b0:670:3b53:9bc with SMTP id\n 4fb4d7f45d1cf-679bb04a826mr226785a12.4.1777331688162;\n Mon, 27 Apr 2026 16:14:48 -0700 (PDT)","Message-ID":"<046bc251-83be-4017-9446-04a7de292cd5@gmail.com>","Date":"Tue, 28 Apr 2026 02:14:45 +0300","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v4] c++/reflection: ICE on member function template\n splicing [PR124794]","To":"Jason Merrill , gcc-patches@gcc.gnu.org","Cc":"Marek Polacek ","References":"<834e4d1f-cad9-4e33-bde4-cfaf768a8271@gmail.com>\n <20260427182331.85714-1-feedabl3@gmail.com>\n ","Content-Language":"en-US","From":"feedable ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3683452,"web_url":"http://patchwork.ozlabs.org/comment/3683452/","msgid":"<59f1660b-7522-4e11-be76-3753166128fa@gmail.com>","list_archive_url":null,"date":"2026-04-28T13:14:53","subject":"Re: [PATCH v4] c++/reflection: ICE on member function template\n splicing [PR124794]","submitter":{"id":92146,"url":"http://patchwork.ozlabs.org/api/people/92146/","name":"feedable","email":"feedabl3@gmail.com"},"content":">>     (tsubst_expr): Defer to tsubst_splice_expr when thetemplate part of\n>>     TEMPLATE_ID_EXPR is a SPLICE_EXPR\n>>     * reflect.cc (check_splice_expr): Add handling for BASELINKs\n>\n> I still think MAYBE_BASELINK_FUNCTIONS or maybe_get_first_fn at the \n> top of check_splice_expr can replace changing multiple places in the \n> function.  Nothing in this function is interested in a BASELINK. \nEven if MAYBE_BASELINK_FUNCTIONS works, maybet_get_first_fn won't, since \nthat also strips TEMPLATE_ID_EXPR, which we are very interested in. We \ndo need to strip that in the cases where it is used, though, so we won't \ngain anything by putting the strip for BASELINKs at the top.","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=iSRY2Xkm;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=2620:52:6:3111::32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (2048-bit key,\n unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256\n header.s=20251104 header.b=iSRY2Xkm","sourceware.org;\n dmarc=pass (p=none dis=none) header.from=gmail.com","sourceware.org; spf=pass smtp.mailfrom=gmail.com","server2.sourceware.org;\n arc=none smtp.remote-ip=209.85.128.45"],"Received":["from vm01.sourceware.org (vm01.sourceware.org\n [IPv6:2620:52:6:3111::32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g4gsV5nY3z1yHv\n\tfor ; Tue, 28 Apr 2026 23:15:25 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id 9DCAD4BABF3F\n\tfor ; Tue, 28 Apr 2026 13:15:23 +0000 (GMT)","from mail-wm1-f45.google.com (mail-wm1-f45.google.com\n [209.85.128.45])\n by sourceware.org (Postfix) with ESMTPS id 38E664BA900B\n for ; Tue, 28 Apr 2026 13:14:57 +0000 (GMT)","by mail-wm1-f45.google.com with SMTP id\n 5b1f17b1804b1-4891d7164ddso58030715e9.3\n for ; Tue, 28 Apr 2026 06:14:57 -0700 (PDT)","from ?IPV6:2a02:8308:900b:fc00::2690? ([2a02:8308:900b:fc00::2690])\n by smtp.gmail.com with ESMTPSA id\n 5b1f17b1804b1-48a773aeb49sm55298515e9.4.2026.04.28.06.14.54\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Tue, 28 Apr 2026 06:14:54 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org 9DCAD4BABF3F","OpenDKIM Filter v2.11.0 sourceware.org 38E664BA900B"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 38E664BA900B","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 38E664BA900B","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777382097; cv=none;\n b=lr/MG4UDg/TahSR/4e3700gSLGmb/ebztYY0UecHVFX/D1n9NR/a89AftqJ2bqljC4z4J4EL5QRQk4qbw3f1DTJgbkpSnA5e876iskhD7bEkBN3TVjl9Oqes+EQr88D1a74cmKH7vdvAhoQk2m3cRZQ5a93L0LmPJjflonAWtSs=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777382097; c=relaxed/simple;\n bh=R2ZkRJIoLen2Qs21q+tK9VQn8RqVn66h/NzjKKiQxBg=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=A/uvQqWewCVy0rwx48FUuk/U31gMsMS7jwktF83iKd1n4iaYEPyh0WCD3I1f0iptSprD1VWy/NveZSXklZ3kwiZEYXdDs/0W+3s+/h6V/G31dH+QpoFGwIoEXRc5T4QTGuvA3oosjLvQAxnTzbmhLv2HEbZO56ZNatJJEdIXyT4=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=gmail.com; s=20251104; t=1777382096; x=1777986896; darn=gcc.gnu.org;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :from:to:cc:subject:date:message-id:reply-to;\n bh=gPrfeocuQHQyJnVdOn5eKYAwjerCZMBfMwr8Z1GGoaU=;\n b=iSRY2XkmnSec5RuHQzb+xg2NqJyJ0jIUj6Gf6rHd18poavN3Ca6EoIeXepKtwO6GoS\n Iqo0PH2eidpyK5Y5OaxSmMksLPVDIF86IlVEBq2hJl8aUQ1y9XSh/cP/au3TgdVSBaf8\n zfZu6+whLGNEf5n9Y58uFgbpt5A1FXf8rxa3/slRIhHf4i3HLH2oTsoRjS/mLx+21I69\n e4g5nqkFkVnwHZi+FIAi3HHXW7UL40XT+kWWJNjnpNx8si+eWwaJyLQf0Z64UdczIqe2\n f1qgZop0fObYtLUuN45q+8Zil3q7THpzDeAweiBI186bQXzAZ5geCTvi0tmOOqz+Nj/h\n faRQ==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777382096; x=1777986896;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=gPrfeocuQHQyJnVdOn5eKYAwjerCZMBfMwr8Z1GGoaU=;\n b=Ycsu9GEFOMwXeMhGivqxQkcHeZyIKmT9Uka6UrF9s1VpD+8oBizlCXixulcnMSCGK0\n 7Bil6dKdI7+tGN0uXTQLXHg3eW0rkdaIziB4G/V1j617F+Vxw06ZLlWIrXZaRh0VAn6v\n +vgmXO70ear8zlIlwJzmgReAgGcOMFSNBUJYEAs4JGmpGpa2H7N/cCFB7F3FLyOJXHHO\n 1FOI9THHKKVX/4m93t6FTW5twfYm5taEKcJ7lYpRCDlAqoybet9MXGUg4HwapwTUWtaa\n x2/XzofMLPgq67lW1BuSeXH7yNGxH8p+RxgOZ9+CIIs4vYTWzvpL8bspqXOb39TWVqDY\n cARA==","X-Forwarded-Encrypted":"i=1;\n AFNElJ9dUzOMXFi2Y03dUSU7kSB+A2ve9t5ZQqw38Lmsgsr/B62VFGJacaIUMguyeApSwMqMjJTq261drkeViw==@gcc.gnu.org","X-Gm-Message-State":"AOJu0Yw2nAFZLn9sJtysAgg9HdmhU8kvRfX0eMgvZ8wPyQqAr42Oe40R\n L3vQJouPRWoYTn6vStLYJJecSJHttzdk2eE7AOYe6o6xhp/mhouwoS+a","X-Gm-Gg":"AeBDieucF0tlYbQupfHX3COl/W8iQinv2LuZP5+RacRKUs6iKje+e1Y4s5fs6fM+EMJ\n vCryFmlaWcikJF8JV19brzMOuvqu4DX7QNthysnATnErN8ZvuZ8WZ7CoO/Zc55pNrurO6zELt9e\n hDIIzNgwCR34EJ4Epg9eJ0bw1IQSa03IqbnVwhVCSZsYxWou4ZXmm1no+hsBAAQRAVIe7JT5TvG\n AXfOtfwOauzP4kWIu3Wdi2s/QRxnEqyIT1beq2i1om2j3nss5DZR59s6Ur/CAsGjb+Bb7KTP1UV\n SOR+Oib02rXVhzhG+Y0esI86zgmr38xGr0Hp5PzTq59PBOsLOP0WdngPqpuenhE9p8JuCgiRV/v\n AYAABQ8YaFO1x8CTrr4OO4O125oArkWGyZfmrdBO8/9knWREtF0hzbFk5IyR/n0PNv4jdRcXFZX\n 9A6Yqo8VqHmhmmi63V8U3mUKPa8P6rQsajJdnRdezRM6RP+A==","X-Received":"by 2002:a05:600c:1e8b:b0:486:f634:ef1 with SMTP id\n 5b1f17b1804b1-48a77b171afmr49309315e9.17.1777382095644;\n Tue, 28 Apr 2026 06:14:55 -0700 (PDT)","Message-ID":"<59f1660b-7522-4e11-be76-3753166128fa@gmail.com>","Date":"Tue, 28 Apr 2026 16:14:53 +0300","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v4] c++/reflection: ICE on member function template\n splicing [PR124794]","To":"Jason Merrill , gcc-patches@gcc.gnu.org","Cc":"Marek Polacek ","References":"<834e4d1f-cad9-4e33-bde4-cfaf768a8271@gmail.com>\n <20260427182331.85714-1-feedabl3@gmail.com>\n ","Content-Language":"en-US","From":"feedable ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}},{"id":3683679,"web_url":"http://patchwork.ozlabs.org/comment/3683679/","msgid":"<876ad38e-b543-4710-bf45-c020e1951486@redhat.com>","list_archive_url":null,"date":"2026-04-28T19:10:52","subject":"Re: [PATCH v4] c++/reflection: ICE on member function template\n splicing [PR124794]","submitter":{"id":4337,"url":"http://patchwork.ozlabs.org/api/people/4337/","name":"Jason Merrill","email":"jason@redhat.com"},"content":"On 4/27/26 7:14 PM, feedable wrote:\n> \n> On 28/04/2026 01:03, Jason Merrill wrote:\n>> On 4/27/26 2:14 PM, feedable wrote:\n>>>>>>>>> +          else if (BASELINK_P (expr))\n>>>>>>>>> +        expr  = build_baselink (access_path, BASELINK_BINFO \n>>>>>>>>> (expr),\n>>>>>>>\n>>>>>>> Extra space before =.  Also I guess BASELINK_ACCESS_BINFO instead of\n>>>>>>> BASELINK_BINFO?\n>>>>>>\n>>>>>> We want to use access_path (relative to the actual object_type) in \n>>>>>> place of\n>>>>>> BASELINK_ACCESS_BINFO, but indeed the access path should be the \n>>>>>> second\n>>>>>> argument rather than the first in both this call and the existing \n>>>>>> one.\n>>>>>\n>>>>> If I understand correctly, access_path is the endpoint of the \n>>>>> search, so it\n>>>>> should go into BASELINK_BINFO, and it's the object type that should go\n>>>>> into BASELINK_ACCESS_BINFO (in both cases, actually), since it's the\n>>>>> place where we started the search.\n>>>>\n>>>> Ah, true.\n>>>\n>>> Apparently, the start would actually correspond to the time when we got\n>>> the reflection in the first place (as we are essentially performing\n>>> x.C::m, but with C::m being spliced); so obtaining the access binfo \n>>> from the\n>>> reflection here is correct.\n>>\n>> I think you were right before; the reflection of a member does not \n>> include any information about how it was produced, whether from ^^ \n>> directly or otherwise.  And normally BASELINK_ACCESS_BINFO needs to \n>> represent either the object type or a base thereof.\n> I believe that information is set in https://forge.sourceware.org/gcc/ \n> gcc-TEST/src/commit/c607c686100689e3e68487cd8097c2fbd3904168/gcc/cp/ \n> parser.cc#L10181, at least for the ^^ case.\n>> So using TYPE_BINFO (object_type) as in v3 makes sense.  Of course \n>> we're suppressing access checking anyway so it doesn't much matter, \n>> but better to be correct if it isn't a burden.\n> Consider this case:\n> ```\n> struct X {};\n> struct Y { template T f(T); };\n> auto _ = X{}.[:^^Y::f:](1);\n> ```\n> \n> Here, in v3 we build a BASELINK with the start point at X, even though X \n> has nothing to do with Y::f, we couldn't've possibly found Y::F through \n> X.\n\nHmm, in that case lookup_base should fail so we don't build a BASELINK \nat all.\n\n> This ends up confusing the access checks in \n> adjust_result_of_qualified_name_lookup in \n> cp_parser_postfix_dot_deref_expression and crashing. In fact, there is a \n> test for this (member13.C) and v3 will fail it, but I somehow didn't \n> catch that at first.\n\n>>> +      if (SPLICE_EXPR_MEMBER_ACCESS_P (t))\n>>> +    return template_id;\n>>\n>> On this return you miss substituting the template arguments. \n> \n> True.\n> \n>> And I think this if/return shouldn't be necessary if we pass \n>> tf_no_name_lookup down as suggested below.\n> \n> For the reasons below, we at most can pass that flag for the access \n> case, so within tsubst_splice_expr itself.\n> \n>>> +      op = tsubst_expr (template_id, args, complain, in_decl);\n>>\n>> I'm a bit uncomfortable with substituting op a second time, but I \n>> guess it should be stable.\n> \n> We aren't, really.\n\nI mean this passes the result of tsubst_expr back to tsubst_expr (inside \nthe template_id). In general that isn't safe because the first call \ncould produce non-template trees such TARGET_EXPR.\n\n> The first substitution only concerns the operand of \n> the splice expr, so that we get the template decl back. The second \n> substitution is supposed to substitute the template arguments into that \n> template, yielding an actual entity.\n\nYes, that we get a decl back is why I think it's fine.\n\n>>> @@ -21450,6 +21467,9 @@ tsubst_expr (tree t, tree args, \n>>> tsubst_flags_t complain, tree in_decl)\n>>>       tree templ = TREE_OPERAND (t, 0);\n>>>       tree targs = TREE_OPERAND (t, 1);\n>>>   +    if (TREE_CODE (templ) == SPLICE_EXPR)\n>>> +      return tsubst_splice_expr (t, args, complain, in_decl);\n>>\n>> I think we want complain|no_name_lookup_flag here.\n> \n> As I understand the meaning of that flag, we do want that if we don't do \n> member access.\n\nYes, that's why \"no_name_lookup_flag\" (the local variable) rather than \n\"tf_no_name_lookup\". We want the recursive substitution of the \nTEMPLATE_ID to have that flag iff the original one did.\n\n>> I still think MAYBE_BASELINK_FUNCTIONS or maybe_get_first_fn at the top of check_splice_expr can replace changing multiple places in the function. Nothing in this function is interested in a BASELINK. \n> Even if MAYBE_BASELINK_FUNCTIONS works, maybe_get_first_fn won't, since that also strips TEMPLATE_ID_EXPR, which we are very interested in.\n> We do need to strip that in the cases where it is used, though, so we won't gain anything by putting the strip for BASELINKs at the top.\n\nWe gain not needing to decide whether we need to strip it in various \nplaces later in the function. Currently the patch doesn't for the \n[cd]tor check, which seems like an oversight.\n\nLooking back in the conversation:\n\n>> The inform_tree_category call doesn't need maybe_get_first_fn because\n>> it already does it, and only the get_template_info check needs to strip\n>> BASELINKs.\n> \n> The tricky thing here is that it gets the location first, an only after that strips, so the location of the BASELINK(at the callsite) and not of the entity gets emitted in the end. \n\nIt does currently, but is there any reason for that? Why not move \ntaking the location to after the strip?\n\nJason","headers":{"Return-Path":"","X-Original-To":["incoming@patchwork.ozlabs.org","gcc-patches@gcc.gnu.org"],"Delivered-To":["patchwork-incoming@legolas.ozlabs.org","gcc-patches@gcc.gnu.org"],"Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=BpmxBG5y;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org\n (client-ip=38.145.34.32; helo=vm01.sourceware.org;\n envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org;\n receiver=patchwork.ozlabs.org)","sourceware.org;\n\tdkim=pass (1024-bit key,\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=BpmxBG5y","sourceware.org; dmarc=pass (p=quarantine dis=none)\n header.from=redhat.com","sourceware.org; spf=pass smtp.mailfrom=redhat.com","server2.sourceware.org;\n arc=none smtp.remote-ip=170.10.129.124"],"Received":["from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g4qn826dNz1xrS\n\tfor ; Wed, 29 Apr 2026 05:12:10 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id B7D9F4BA7991\n\tfor ; Tue, 28 Apr 2026 19:12:08 +0000 (GMT)","from us-smtp-delivery-124.mimecast.com\n (us-smtp-delivery-124.mimecast.com [170.10.129.124])\n by sourceware.org (Postfix) with ESMTP id 0EAB34BB8F7A\n for ; Tue, 28 Apr 2026 19:10:59 +0000 (GMT)","from mail-qk1-f200.google.com (mail-qk1-f200.google.com\n [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-163-uLGG8iWhNBOqD6bVl9Nh_w-1; Tue, 28 Apr 2026 15:10:56 -0400","by mail-qk1-f200.google.com with SMTP id\n af79cd13be357-8e8950b3ee1so3122001485a.3\n for ; Tue, 28 Apr 2026 12:10:56 -0700 (PDT)","from [192.168.50.130]\n (130-44-146-247.s12789.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com.\n [130.44.146.247]) by smtp.gmail.com with ESMTPSA id\n af79cd13be357-8f7c19ae61bsm272673785a.0.2026.04.28.12.10.53\n (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);\n Tue, 28 Apr 2026 12:10:53 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org B7D9F4BA7991","OpenDKIM Filter v2.11.0 sourceware.org 0EAB34BB8F7A"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 0EAB34BB8F7A","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 0EAB34BB8F7A","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777403459; cv=none;\n b=daQ/KXVGZzuIFLe8FY4kRUCdL4noPhUAMHEmg9NDh+9RdCWLxyFWiekaqUcBV1EeEowZkVvMD6+0ISIZLMbAkwYN8keeaHuLo920BOa9kUfZAgmZXNzYnwhvCRJrtX9nnCGGuFUtXV9ti6rP+VsV7u2DqjwIDnkWaunkNN6NO7Q=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1777403459; c=relaxed/simple;\n bh=lDG5ECCXHV4cJ1Zwg1Xr9o4fV+I+jFz9nbq8hL+9jjQ=;\n h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From;\n b=vB5ciW6CD+foVmkw9pCrNxgcLg5vIuGcsWvWnx/CxcaxWGbJp0lc1IShGbm1KjNPnNMSRtR62kld+J/mKpb2sWxRIH0PraKoZRakaSYcCIxtVQs9LAJnNn0GyaF4mrEGMFLrsPUqisN1IhX6O0atWgNwuQMgGh16X55VjosLG6c=","ARC-Authentication-Results":"i=1; server2.sourceware.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1777403458;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=ZQKyZxDRFEZ75ZwGK251buA3JrrJCkvkQEudIJ1ekGk=;\n b=BpmxBG5yTmy8UsdBr0Ksa4CfjjkpdbrC9hZbMETI2nFDHbK19LvJ7mgf/TJhxlhaXMUqV8\n sLfMjeBT5D6fvaxr3fMJF4C1TGHHG4Alm1gIxPtvPM9sDT3K63Gr2Ae0b4wodo5j4aDqub\n Oo5h9lMi2GbOshd92ijcDpMovqb/ePU=","X-MC-Unique":"uLGG8iWhNBOqD6bVl9Nh_w-1","X-Mimecast-MFC-AGG-ID":"uLGG8iWhNBOqD6bVl9Nh_w_1777403455","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1777403455; x=1778008255;\n h=content-transfer-encoding:in-reply-to:from:content-language\n :references:cc:to:subject:user-agent:mime-version:date:message-id\n :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=ZQKyZxDRFEZ75ZwGK251buA3JrrJCkvkQEudIJ1ekGk=;\n b=qi//hEDQhemCBoHUqd8xWLEIPAKEaNeN2SdATNn1giGErsE+0SfjOlKlC/oTYagDID\n eZAQnzVCJko3ntnPqcqFst70GPNpPE711hLoFVMiyrjhMW3u2OKlHsstKnG3UyERmTcQ\n Oi7xnLi6LwxjG91LnjycJ3c2nQCx6o0GVDHQnsFq6sd0B/R3ZTZ+fH+4c671rD0m0iA1\n RcZpaP5R0ynhb+LvhRCiIHwnsAVUr6Reuh4AR+JBVxUb/IyqPOCkX9Yxa7oZbkU/4xKF\n lwQAOjj3MYu7aX3l+RmyYApc2VoU/HFE49JKMzh1y7UtyLgZ6K7ayQaO94GbRBYZSpnS\n dFCg==","X-Forwarded-Encrypted":"i=1;\n AFNElJ8Xqbvv30GDDEPQl7CaYNoFyZbxFPVECSUvL93fR2Esow7/yl9remn8ssYSApMHmnHYYmONSY19vtKkEQ==@gcc.gnu.org","X-Gm-Message-State":"AOJu0YxoHjVFVNHCawcs3/ZCWg6CbLXBs/hnR2S6NTNKfRtesBwb0ufa\n DwIGDvz9k9LtWHrok4jf8UOWby1Ru4I9dbuOuFFGw6WId73zTG1JB/eus1gQVp+BHVDZz1MsrfQ\n 4zZy1hocnIr4XOWto/9ECu56ER+7UKQ6//5EWfb5iTG5PvAstwVInZuw+IXA=","X-Gm-Gg":"AeBDiesyaYqePbKAxTQlLzQc1D0WbQc9sUlzYE80CR30r4x0uJf9rHKdnrwG9Exb6Bg\n 0ytIppAj/8yI/0v0BdOEfl8x8sgluBK60LPLlbi54fzZqUyS10JZ/sv6ZXrBM5KehHRWYTuxvTU\n Yu+RhAg95JFY4CAGY/vCha35Xsab68/UfDnNZG4SnclUsFY9SrCqPCWXxLi6bNOIddy4zKvsarm\n AZURId5+uE8xBVikeHxfMCooSMX8mi8ScsPamoftMck20IoUtsoFeeNELiJg1a42sbs0sCL4aV+\n +KxT2PWPy/RcsceghWVW1Cn0V19eqP4D7y4/iVAleAZBKHcgHEmvXBef0AlbNMGRUz8L1Iiz0Zu\n I34A5YTHj/kBG3zy9P/urzd4iQ/QtLZVELpsVDB/AwuB3aoEaXaUjCZ53Cqpoqsdpqt9YpfDFaI\n 2cLW+iFmzqplPN/DxMm2peoA4/KkL1y6Y2Db/PmXYYsA==","X-Received":["by 2002:a05:620a:460d:b0:8da:d152:b7e2 with SMTP id\n af79cd13be357-8f7d7c224e2mr607978685a.25.1777403455276;\n Tue, 28 Apr 2026 12:10:55 -0700 (PDT)","by 2002:a05:620a:460d:b0:8da:d152:b7e2 with SMTP id\n af79cd13be357-8f7d7c224e2mr607970785a.25.1777403454616;\n Tue, 28 Apr 2026 12:10:54 -0700 (PDT)"],"Message-ID":"<876ad38e-b543-4710-bf45-c020e1951486@redhat.com>","Date":"Tue, 28 Apr 2026 15:10:52 -0400","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v4] c++/reflection: ICE on member function template\n splicing [PR124794]","To":"feedable , gcc-patches@gcc.gnu.org","Cc":"Marek Polacek ","References":"<834e4d1f-cad9-4e33-bde4-cfaf768a8271@gmail.com>\n <20260427182331.85714-1-feedabl3@gmail.com>\n \n <046bc251-83be-4017-9446-04a7de292cd5@gmail.com>","From":"Jason Merrill ","In-Reply-To":"<046bc251-83be-4017-9446-04a7de292cd5@gmail.com>","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"ATIoZxZ6O59bQ7XgIciK4jskqZCmYoD4gkUlJ_1E1j0_1777403455","X-Mimecast-Originator":"redhat.com","Content-Language":"en-US","Content-Type":"text/plain; charset=UTF-8; format=flowed","Content-Transfer-Encoding":"8bit","X-BeenThere":"gcc-patches@gcc.gnu.org","X-Mailman-Version":"2.1.30","Precedence":"list","List-Id":"Gcc-patches mailing list ","List-Unsubscribe":",\n ","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n ","Errors-To":"gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org"}}]