[{"id":3681471,"web_url":"http://patchwork.ozlabs.org/comment/3681471/","msgid":"<13166c64-8c75-f508-35ca-30d2f60cef10@idea>","list_archive_url":null,"date":"2026-04-23T13:39:29","subject":"Re: [PATCH] c++/reflection: erroneous access check on dependent\n splice [PR124989]","submitter":{"id":78319,"url":"http://patchwork.ozlabs.org/api/people/78319/","name":"Patrick Palka","email":"ppalka@redhat.com"},"content":"On Wed, 22 Apr 2026, Marek Polacek wrote:\n\n> Tested dg.exp on x86_64-pc-linux-gnu, ok for trunk/16.2?\n\nOK\n\n> \n> Though, I'd like to push this to 16.1 if possible, it seems\n> safe and looks relatively important.\n> \n> -- >8 --\n> When processing &[:R:] in cp_parser_splice_expression, we call\n> build_offset_ref with access checking turned off via push_ and\n> pop_deferring_access_checks, but the same pair of calls is not\n> present around the call to build_offset_ref in tsubst_splice_expr\n> and so the following test fails to compile due to access control\n> checking failures.\n> \n> \tPR c++/124989\n> \n> gcc/cp/ChangeLog:\n> \n> \t* pt.cc (tsubst_splice_expr): Turn off access checking for the\n> \tbuild_offset_ref call.\n> \n> gcc/testsuite/ChangeLog:\n> \n> \t* g++.dg/reflect/member24.C: New test.\n> ---\n> gcc/cp/pt.cc | 2 ++\n> gcc/testsuite/g++.dg/reflect/member24.C | 25 +++++++++++++++++++++++++\n> 2 files changed, 27 insertions(+)\n> create mode 100644 gcc/testsuite/g++.dg/reflect/member24.C\n> \n> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc\n> index 5d97ca7997f..7e755193f4e 100644\n> --- a/gcc/cp/pt.cc\n> +++ b/gcc/cp/pt.cc\n> @@ -16957,12 +16957,14 @@ tsubst_splice_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)\n> \n> if (SPLICE_EXPR_ADDRESS_P (t))\n> {\n> + push_deferring_access_checks (dk_no_check);\n\nSide note but IMHO dk_deferred should generally be used instead of\ndk_no_check (despite their names). That's because dk_no_check is very\nsticky and cannot be undone by nested callers, so if say\nbuild_offset_ref requires class template instantiation, constraint\nsatisfaction etc, then that will be done with access checking disabled\ntoo! I don't think that's an issue here so I'm good with the patch\nas-is. The dk_no_check vs dk_deferred is widespread throughout the FE\nso it makes sense to address it as a separate comprehensive patch.\n\n> if (BASELINK_P (op))\n> \top = build_offset_ref (BINFO_TYPE (BASELINK_ACCESS_BINFO (op)), op,\n> \t\t\t /*address_p=*/true, complain);\n> else if (DECL_NONSTATIC_MEMBER_P (op))\n> \top = build_offset_ref (DECL_CONTEXT (op), op,\n> \t\t\t /*address_p=*/true, complain);\n> + pop_deferring_access_checks ();\n> }\n> \n> if (outer_automatic_var_p (op))\n> diff --git a/gcc/testsuite/g++.dg/reflect/member24.C b/gcc/testsuite/g++.dg/reflect/member24.C\n> new file mode 100644\n> index 00000000000..461b8b35f30\n> --- /dev/null\n> +++ b/gcc/testsuite/g++.dg/reflect/member24.C\n> @@ -0,0 +1,25 @@\n> +// PR c++/124989\n> +// { dg-do compile { target c++26 } }\n> +// { dg-additional-options \"-freflection\" }\n> +\n> +using info = decltype(^^::);\n> +\n> +template \n> +constexpr auto pointer_of()\n> +{\n> + return &[: R :];\n> +}\n> +\n> +struct X\n> +{\n> + int a;\n> +protected:\n> + int b;\n> +private:\n> + int c;\n> +\n> +public:\n> + static constexpr auto pa = pointer_of<^^X::a>();\n> + static constexpr auto pb = pointer_of<^^X::b>();\n> + static constexpr auto pc = pointer_of<^^X::c>();\n> +};\n> \n> base-commit: b6e40cf38c60d11c4e105f9179a6d5cfb502bd9b\n> -- \n> 2.53.0\n> \n>","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=QvvzP6q7;\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=QvvzP6q7","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 4g1cfH1GcMz1y2d\n\tfor ; Thu, 23 Apr 2026 23:40:05 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id E356C4BBAFE9\n\tfor ; Thu, 23 Apr 2026 13:40:02 +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 10ED14BBA164\n for ; Thu, 23 Apr 2026 13:39:35 +0000 (GMT)","from mail-qv1-f69.google.com (mail-qv1-f69.google.com\n [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-684-b_rfHc6lP6aR804PbvtTQA-1; Thu, 23 Apr 2026 09:39:32 -0400","by mail-qv1-f69.google.com with SMTP id\n 6a1803df08f44-8a016b99579so24344486d6.0\n for ; Thu, 23 Apr 2026 06:39:32 -0700 (PDT)","from [2600:4040:aa66:bf00:9e8e:99ff:fed1:71f]\n ([2600:4040:aa66:bf00:9e8e:99ff:fed1:71f])\n by smtp.gmail.com with ESMTPSA id\n 6a1803df08f44-8b205cc0353sm48624476d6.10.2026.04.23.06.39.30\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Thu, 23 Apr 2026 06:39:30 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org E356C4BBAFE9","OpenDKIM Filter v2.11.0 sourceware.org 10ED14BBA164"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 10ED14BBA164","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 10ED14BBA164","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776951575; cv=none;\n b=i9R348i+ShDTN5jnDfktCcDmj/qro0FReDIJNlj5KSnuAU9qzrU4EVVtqf/UpEorvQS0hT+91KKi48nPYZVTjj8RR+rzGUvf/vqQOt8EtjajPa20R9vIRoarmnbxDgnHl9BCIfc/kFWX06VUZ/KQk5+2o6kBIfmXt5O1PG/UT0c=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776951575; c=relaxed/simple;\n bh=r416NUIzB5rNTTi3VuaM8ABxoALkKWio5JqMlGTpg9s=;\n h=DKIM-Signature:From:Date:To:Subject:Message-ID:MIME-Version;\n b=qsks6lIis8d3soeXCr0zqqbiaL27+Ka1KI+z9HHgpLTh/6Dr8hsetyEMYQGnzD0KAcEBcji8iIAnZZ6HF6UOb7VwyPSa2vl5umDfAU/ttIjf8nfmyfa2iqutoDGWxTXWRg06+zj9A5RFaaK+fhH6hLiCiK80qcx586mTM7OMgXo=","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=1776951574;\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 in-reply-to:in-reply-to:references:references;\n bh=PxPX1rjtbeq/8IrxH7gDScMzHdPA3a+LkVVfolWokJw=;\n b=QvvzP6q7v3EL7lpDtLxINjBvMyQR+Nx89oATMcJsvXhuHhv6neM7/d/Eceq8PE2T6Pwut4\n BFy7x3SlwTrLODfBYCrVkSXMPmjtA/NaNfoquy8mqfARaFXbGiSPZ9rvc+rpMNTv54skwQ\n xni24t+mB5H9dfKuNYDE/9iEpgtzXVU=","X-MC-Unique":"b_rfHc6lP6aR804PbvtTQA-1","X-Mimecast-MFC-AGG-ID":"b_rfHc6lP6aR804PbvtTQA_1776951572","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776951572; x=1777556372;\n h=mime-version:references:message-id:in-reply-to:subject:cc:to:date\n :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id\n :reply-to;\n bh=PxPX1rjtbeq/8IrxH7gDScMzHdPA3a+LkVVfolWokJw=;\n b=MkXZYqsAxIPt7yaUifh417+rUYHKRjexXNtivSW/SmK/OKZh19F7IJO9B3t5g5HMW1\n XeR0z+REVUhc/arTeckUIXewKR+KncztbrtnqVHX0S62tod9L2+VJUi/AB0S6OpH9o8Q\n ZqEzF1tjaU93UtxPHrjbMMUxjle+ts+YHGxd9bvgX4PKxMtk7e0Q8Mf9C4veBVlnuyoZ\n ULY/EtuCImju+zyc4KVtPI6rZtGbOcMWodLGyqqk+kA35hXozd0FnBYzwgjXCkbtw7wA\n I2BXz9rQIZKId9pp3dwYjj8sqRLgoDlSJSl6rzaDrxja8pMbRKAC4zXZLwhTSWPCwO/U\n Kr+Q==","X-Gm-Message-State":"AOJu0YzyIiKrwoPoxroE1bc1+Yr56fshdQuM472dEMCP4qdTTZyVLcnJ\n +IoggmvlJlbyPWN+zwxlQXqHM/Y+lIBMHhmCFdXAA7fLcfElfH00gk7QOQ5G+BSUinNLK2mxyKf\n CUJAM7y3noapOCdrXW1kea24NtEx4Nk/zEVN35QDajftZcY48nEnFqDm2a3o=","X-Gm-Gg":"AeBDievTJfbudFbd4xFxXINFX6JzmtrV6u1RoTelUKm/MGNR0ONQJiCxnLQLhKV3Mwn\n NtyGtuf2IuQxElSAT8MMQs4wyViuRPBeX4NOf13sPza8JBn9vErsVEzioJ94saAtsNwI6ot+Mpu\n 4MX1HKeq0kU7MUv+SBjITf01YAJKqXOqpztj0rJolx75Xk7YXDN3KXNMZG1OlYggXPV6Dw9y4cC\n t/yJppYnXri9bs/FxgeloMa2h5b29L2wRte8vuvXDEfquCDS+QClaRbcZoVqeSE90x5NSzGpB9f\n 7Q35Q/o9W05f/Fa9Z7NrX++O4uo3dNc7+2fgX+Vvb8pqcgsz+uFyDFS8meMK72QzmaXZOdO6YXX\n khltDcMsWzWwpP30fwOLwM6co08lBSZdVcB1xK3llxL8Gm4Cl2GF+/SeGgZ9dOOpJ","X-Received":["by 2002:ad4:5d41:0:b0:8ae:5ea3:3a79 with SMTP id\n 6a1803df08f44-8b028176d4emr295772156d6.6.1776951571874;\n Thu, 23 Apr 2026 06:39:31 -0700 (PDT)","by 2002:ad4:5d41:0:b0:8ae:5ea3:3a79 with SMTP id\n 6a1803df08f44-8b028176d4emr295771836d6.6.1776951571367;\n Thu, 23 Apr 2026 06:39:31 -0700 (PDT)"],"From":"Patrick Palka ","X-Google-Original-From":"Patrick Palka ","Date":"Thu, 23 Apr 2026 09:39:29 -0400 (EDT)","To":"Marek Polacek ","cc":"GCC Patches , Jason Merrill ,\n Patrick Palka , Jakub Jelinek ","Subject":"Re: [PATCH] c++/reflection: erroneous access check on dependent\n splice [PR124989]","In-Reply-To":"<20260422220620.2017820-1-polacek@redhat.com>","Message-ID":"<13166c64-8c75-f508-35ca-30d2f60cef10@idea>","References":"<20260422220620.2017820-1-polacek@redhat.com>","MIME-Version":"1.0","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"XMO6DMWjfuJ2G7hF1uzTfI__qko0eGxfo44eMtwAYrQ_1776951572","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain; charset=US-ASCII","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":3681496,"web_url":"http://patchwork.ozlabs.org/comment/3681496/","msgid":"","list_archive_url":null,"date":"2026-04-23T14:24:41","subject":"Re: [PATCH] c++/reflection: erroneous access check on dependent\n splice [PR124989]","submitter":{"id":78319,"url":"http://patchwork.ozlabs.org/api/people/78319/","name":"Patrick Palka","email":"ppalka@redhat.com"},"content":"On Thu, Apr 23, 2026 at 10:21 AM Marek Polacek wrote:\n>\n> On Thu, Apr 23, 2026 at 09:39:29AM -0400, Patrick Palka wrote:\n> > On Wed, 22 Apr 2026, Marek Polacek wrote:\n> >\n> > > Tested dg.exp on x86_64-pc-linux-gnu, ok for trunk/16.2?\n> >\n> > OK\n> >\n> > >\n> > > Though, I'd like to push this to 16.1 if possible, it seems\n> > > safe and looks relatively important.\n> > >\n> > > -- >8 --\n> > > When processing &[:R:] in cp_parser_splice_expression, we call\n> > > build_offset_ref with access checking turned off via push_ and\n> > > pop_deferring_access_checks, but the same pair of calls is not\n> > > present around the call to build_offset_ref in tsubst_splice_expr\n> > > and so the following test fails to compile due to access control\n> > > checking failures.\n> > >\n> > > PR c++/124989\n> > >\n> > > gcc/cp/ChangeLog:\n> > >\n> > > * pt.cc (tsubst_splice_expr): Turn off access checking for the\n> > > build_offset_ref call.\n> > >\n> > > gcc/testsuite/ChangeLog:\n> > >\n> > > * g++.dg/reflect/member24.C: New test.\n> > > ---\n> > > gcc/cp/pt.cc | 2 ++\n> > > gcc/testsuite/g++.dg/reflect/member24.C | 25 +++++++++++++++++++++++++\n> > > 2 files changed, 27 insertions(+)\n> > > create mode 100644 gcc/testsuite/g++.dg/reflect/member24.C\n> > >\n> > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc\n> > > index 5d97ca7997f..7e755193f4e 100644\n> > > --- a/gcc/cp/pt.cc\n> > > +++ b/gcc/cp/pt.cc\n> > > @@ -16957,12 +16957,14 @@ tsubst_splice_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)\n> > >\n> > > if (SPLICE_EXPR_ADDRESS_P (t))\n> > > {\n> > > + push_deferring_access_checks (dk_no_check);\n> >\n> > Side note but IMHO dk_deferred should generally be used instead of\n> > dk_no_check (despite their names). That's because dk_no_check is very\n> > sticky and cannot be undone by nested callers, so if say\n> > build_offset_ref requires class template instantiation, constraint\n> > satisfaction etc, then that will be done with access checking disabled\n> > too! I don't think that's an issue here so I'm good with the patch\n> > as-is. The dk_no_check vs dk_deferred is widespread throughout the FE\n> > so it makes sense to address it as a separate comprehensive patch.\n>\n> I'm sure my logic was that I wanted to completely elide the checking,\n> not just defer it. But there are other access checking with reflection\n> PRs so maybe we'll have to revisit this. As you say, they should be\n> changed in lockstep if needed though.\n\nYeah, the approach would be to use dk_deferred and then just throw\naway the deferred checks without actually checking them\n\n>\n> Marek\n>","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=IZ3O+JsS;\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=IZ3O+JsS","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 4g1dfm4hdpz1yD5\n\tfor ; Fri, 24 Apr 2026 00:25:36 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id CACC84BC0C22\n\tfor ; Thu, 23 Apr 2026 14:25:34 +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 CCCA84BBF6D4\n for ; Thu, 23 Apr 2026 14:24:57 +0000 (GMT)","from mail-ed1-f69.google.com (mail-ed1-f69.google.com\n [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-696-EJMt54XmOy-zS3rrJxsYxw-1; Thu, 23 Apr 2026 10:24:55 -0400","by mail-ed1-f69.google.com with SMTP id\n 4fb4d7f45d1cf-671c1685ee8so345303a12.0\n for ; Thu, 23 Apr 2026 07:24:54 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org CACC84BC0C22","OpenDKIM Filter v2.11.0 sourceware.org CCCA84BBF6D4"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org CCCA84BBF6D4","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org CCCA84BBF6D4","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776954297; cv=none;\n b=WB0GbV734tCXud9ny0iXHC7qlD0sUojtdsTVT9DR6wzkgkVks4S0J3Rq/mXSoQPlQv+ziBiUmfLQx+u1TqqwI+gIPWhC9Q1qcApnplAbT1tBlN0xzciTO6iD+apWZDmq29ipW9/pKihYIR158k5fNyMJZlDnptbVB9ChlJDGXkI=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776954297; c=relaxed/simple;\n bh=+kWLGm7WW1JOieg4+woXGmcYPL4Pb8TRTXnp/Tp3Y24=;\n h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;\n b=a52a2JnTCnKDUZ1RFvW89osRo/qTR5scWCawzhQm+RnZD8XLJOXDzBVv+vop7eqNT9UH/wanaJ3peAYa5ArQ+Wzc7b0wK+8XG86/Nf9Y1uZEqEU8qxdjgmHHOKVbRtycWglpNfWxy4NWQ6FMBTgszN9Utj256wFBbDIEYJUdd2A=","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=1776954297;\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=PCQ7A1zcMReHbfgFlU1kP+KgZoMT82YQo/2Qcfp/LBc=;\n b=IZ3O+JsSiUHIy3vWAOX+2T6MoUwUeyg57ienUPngM7a2jvopUDpOmAnSAqYxMpwuJGatdc\n YUrLlIfAhfSRd3PbOYqzhMKSmmSOe345htRQUVbTqvNB/pEeBVTJyQrkDQbF3vqSbyiN+U\n lBHahe/k/KaZggnFe6sObIpWrMdqXxA=","X-MC-Unique":"EJMt54XmOy-zS3rrJxsYxw-1","X-Mimecast-MFC-AGG-ID":"EJMt54XmOy-zS3rrJxsYxw_1776954294","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776954294; x=1777559094;\n h=content-transfer-encoding:cc:to:subject:message-id:date:from\n :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=PCQ7A1zcMReHbfgFlU1kP+KgZoMT82YQo/2Qcfp/LBc=;\n b=akjXVTF+6fTXUiIxfPJ4949t8qptSuCwdHaBSieJ8MeXlS9oGIIT6nmjhCU/Q5GI4k\n iH6oF2k48xu0aoZNFnyUsuMM593iVecE9JuqAWdG5Ctn003CemuA/n1hf/YQDjeNPnvh\n A9/7/P/5+1kM517Of96Qu/AQMKHDto7uBj9XJGTEp0sws5vz4NzjpGBeex1fkUMB6Iuw\n tl5D0zm6ObqsTPw/UMtIYajszFy8ahPWw4kAnilSeLXJXh5XldG8aIJJbxa533VI7cX/\n 1nhveqpeSput31EMlcP1eSNcFrZQz+yuAxfcxoVOI5/n30anto/I4NfT4GCAcfxzCycq\n V5fQ==","X-Gm-Message-State":"AOJu0Yxjqexwnje0iuhoewbELPouF0C043B0yUBew4H3qZoVa7W4zosu\n ckTpe5iFbx/yUCPyHAJCziADF7qpl8uLC9+Z0G/uIB9oNH3ac83TzC2it4RqVC2sF4MXv0C/C+j\n GlsBl5lQWSmTfFq5qG1ovi1j+/MdavXvOLPP0JQWOsIlnDcsXEtMwiLvWJ75eFi6g1vH06j+EiJ\n KNhLnfdFNYqVtMIjU2P6xJn0uvsCywU3THXg==","X-Gm-Gg":"AeBDieuhbaL1vvb+jJIia8/Ew3oHX9zYE3EEoXV1FoM3tMOPEdTyteVAw3fQw1yhHTF\n 6EHHcq0IP3CHfmGIydYQ5l2VYFtun1R7MdqEbeps8QoabYv+MGTQEd/V2lYcUsQOX6mJlbv8VrU\n eV9U6bgiWchgJu3CZST+1ttFcjJ6RLoQ2SrtU+GcoWqADn2Dxpt8GIFTbu1NiOrchKDsJPGJALe\n +gkKk9SxJQ9dlpb8nOneVHfqgARcUu7kN/NhTnDxUxizYoUnw==","X-Received":["by 2002:a05:6402:4305:b0:672:a209:373b with SMTP id\n 4fb4d7f45d1cf-672bfdd35f1mr5564337a12.5.1776954293689;\n Thu, 23 Apr 2026 07:24:53 -0700 (PDT)","by 2002:a05:6402:4305:b0:672:a209:373b with SMTP id\n 4fb4d7f45d1cf-672bfdd35f1mr5564326a12.5.1776954293191; Thu, 23 Apr 2026\n 07:24:53 -0700 (PDT)"],"MIME-Version":"1.0","References":"<20260422220620.2017820-1-polacek@redhat.com>\n <13166c64-8c75-f508-35ca-30d2f60cef10@idea>\n ","In-Reply-To":"","From":"Patrick Palka ","Date":"Thu, 23 Apr 2026 10:24:41 -0400","X-Gm-Features":"AQROBzBV8Apn39gOHEo8sxWY0W0kYNl2qi88KPS4nGzGiyYuASMLyppjswikScg","Message-ID":"\n ","Subject":"Re: [PATCH] c++/reflection: erroneous access check on dependent\n splice [PR124989]","To":"Marek Polacek ","Cc":"GCC Patches , Jason Merrill ,\n Jakub Jelinek ","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"eFfpFuhwIPQc2uJr7BLh9S0ZxBu8-HcS7yVvwutzFnA_1776954294","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain; charset=\"UTF-8\"","Content-Transfer-Encoding":"quoted-printable","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":3681497,"web_url":"http://patchwork.ozlabs.org/comment/3681497/","msgid":"","list_archive_url":null,"date":"2026-04-23T14:21:44","subject":"Re: [PATCH] c++/reflection: erroneous access check on dependent\n splice [PR124989]","submitter":{"id":14370,"url":"http://patchwork.ozlabs.org/api/people/14370/","name":"Marek Polacek","email":"polacek@redhat.com"},"content":"On Thu, Apr 23, 2026 at 09:39:29AM -0400, Patrick Palka wrote:\n> On Wed, 22 Apr 2026, Marek Polacek wrote:\n> \n> > Tested dg.exp on x86_64-pc-linux-gnu, ok for trunk/16.2?\n> \n> OK\n> \n> > \n> > Though, I'd like to push this to 16.1 if possible, it seems\n> > safe and looks relatively important.\n> > \n> > -- >8 --\n> > When processing &[:R:] in cp_parser_splice_expression, we call\n> > build_offset_ref with access checking turned off via push_ and\n> > pop_deferring_access_checks, but the same pair of calls is not\n> > present around the call to build_offset_ref in tsubst_splice_expr\n> > and so the following test fails to compile due to access control\n> > checking failures.\n> > \n> > \tPR c++/124989\n> > \n> > gcc/cp/ChangeLog:\n> > \n> > \t* pt.cc (tsubst_splice_expr): Turn off access checking for the\n> > \tbuild_offset_ref call.\n> > \n> > gcc/testsuite/ChangeLog:\n> > \n> > \t* g++.dg/reflect/member24.C: New test.\n> > ---\n> > gcc/cp/pt.cc | 2 ++\n> > gcc/testsuite/g++.dg/reflect/member24.C | 25 +++++++++++++++++++++++++\n> > 2 files changed, 27 insertions(+)\n> > create mode 100644 gcc/testsuite/g++.dg/reflect/member24.C\n> > \n> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc\n> > index 5d97ca7997f..7e755193f4e 100644\n> > --- a/gcc/cp/pt.cc\n> > +++ b/gcc/cp/pt.cc\n> > @@ -16957,12 +16957,14 @@ tsubst_splice_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)\n> > \n> > if (SPLICE_EXPR_ADDRESS_P (t))\n> > {\n> > + push_deferring_access_checks (dk_no_check);\n> \n> Side note but IMHO dk_deferred should generally be used instead of\n> dk_no_check (despite their names). That's because dk_no_check is very\n> sticky and cannot be undone by nested callers, so if say\n> build_offset_ref requires class template instantiation, constraint\n> satisfaction etc, then that will be done with access checking disabled\n> too! I don't think that's an issue here so I'm good with the patch\n> as-is. The dk_no_check vs dk_deferred is widespread throughout the FE\n> so it makes sense to address it as a separate comprehensive patch.\n\nI'm sure my logic was that I wanted to completely elide the checking,\nnot just defer it. But there are other access checking with reflection\nPRs so maybe we'll have to revisit this. As you say, they should be\nchanged in lockstep if needed though.\n\nMarek","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=dWw+TZyz;\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=dWw+TZyz","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 4g1dgZ3z6pz1yD5\n\tfor ; Fri, 24 Apr 2026 00:26:18 +1000 (AEST)","from vm01.sourceware.org (localhost [127.0.0.1])\n\tby sourceware.org (Postfix) with ESMTP id AECDE4B8894A\n\tfor ; Thu, 23 Apr 2026 14:26:16 +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 1DFE34BAE7E9\n for ; Thu, 23 Apr 2026 14:21:51 +0000 (GMT)","from mail-yx1-f71.google.com (mail-yx1-f71.google.com\n [74.125.224.71]) by relay.mimecast.com with ESMTP with STARTTLS\n (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id\n us-mta-628-zsZjTQGxOSGYCwYdROL9kQ-1; Thu, 23 Apr 2026 10:21:49 -0400","by mail-yx1-f71.google.com with SMTP id\n 956f58d0204a3-649deef077eso8863803d50.1\n for ; Thu, 23 Apr 2026 07:21:49 -0700 (PDT)","from redhat.com ([2603:7002:1f00:31d2::1db4])\n by smtp.gmail.com with ESMTPSA id\n af79cd13be357-8e7d8edb795sm1620152785a.25.2026.04.23.07.21.45\n (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);\n Thu, 23 Apr 2026 07:21:47 -0700 (PDT)"],"DKIM-Filter":["OpenDKIM Filter v2.11.0 sourceware.org AECDE4B8894A","OpenDKIM Filter v2.11.0 sourceware.org 1DFE34BAE7E9"],"DMARC-Filter":"OpenDMARC Filter v1.4.2 sourceware.org 1DFE34BAE7E9","ARC-Filter":"OpenARC Filter v1.0.0 sourceware.org 1DFE34BAE7E9","ARC-Seal":"i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1776954111; cv=none;\n b=VRkP6G5i9V+es28bjPY1LeOqUsdNzZ7ujwEX5mz7y8Bmfv3IREsRO0qFwtP7DWZ8a91SMVW6eS3t9YXuSt2/UjLe+m9DubaZVzIfQ4iNxWpt2GnG1bGIlpI21I/v70HTPBAihaK1W9uHIoQCsOsgd64DyPMFQZtzVN6kKyqSa0I=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=sourceware.org; s=key;\n t=1776954111; c=relaxed/simple;\n bh=IdTukT0UoAuZLKAkRyiUUEMVUHY9wfokVPG6ALO8C3w=;\n h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;\n b=lXGDcGCRa7vwL8VVQZOQXz7+vZEneyi0NXc4mNm9z8pdUBCTjvfCD8aNmLtuebYG9Sp/NKWKq4VvB9KaIj/2m/4j0rjFGnB/rfjcg9GHEW6Q40ZnXMFwMER1SaeaGw5XJp6XjCCQ7teNf6M9sX22jtMWZYO8TdGJGBYmcE2Mfus=","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=1776954110;\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 in-reply-to:in-reply-to:references:references;\n bh=H8BUKfG3U3d7nzIeUvkVCsnBtzr3HHPMxby7g4aKWXY=;\n b=dWw+TZyzScR051xDSacPoTQmOaEuC6QzHZaKaNbUxGCW/BcKSAExWC32u7+PQMtuADdN0p\n /KYb2i90Ozv7m3VN2u2NfM0RL1Lio/+G61QCQIvs1flg6NnqqowfaZ8+cGBrWNb2eSVblm\n 2i7JJ+xDErWU5XZLPIR2phsI1OSfPGw=","X-MC-Unique":"zsZjTQGxOSGYCwYdROL9kQ-1","X-Mimecast-MFC-AGG-ID":"zsZjTQGxOSGYCwYdROL9kQ_1776954108","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n d=1e100.net; s=20251104; t=1776954108; x=1777558908;\n h=user-agent:in-reply-to:content-disposition:mime-version:references\n :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from\n :to:cc:subject:date:message-id:reply-to;\n bh=H8BUKfG3U3d7nzIeUvkVCsnBtzr3HHPMxby7g4aKWXY=;\n b=GTm7n02pt0ro0LJTwSXG6AwxDgJMw7DVxqOm/mxe7rmMVVC69GozXod71ffkBRyUEh\n FUMAaGmQqLmOfcG8TAwhkAQGCxSY74imIgCzxK+eCbDOV5lmgNgCorNr4sSh9S52FzTO\n Bk5HquUXRpcHlId7dWW9RL5Aaq41plorBbKj2pRIZXHrwEnQuCP+29fwS/sm+8ocUXOw\n yNrBpKF2lbKzGXXPzDrg/7O35nCst4DjqzqKaUNt6+AVfsUlhd9GVbAI+I9FivQM+9uR\n yo3z+djjjalGigkUUVhC878zQozL1l58nh1/Gj56U7q4UzwWr31/I4wPL23mDWgaiT0L\n KyJQ==","X-Gm-Message-State":"AOJu0Yyn8Q1E4AHxnhAxizBcU9cJ6kTAzvW4JTS0e/Xe8UhFEOwUOsrr\n ubOKJmze/48DmxzymzqdqluDsweTh2rB9PEapxxaaJtwA/Oh92Icci3ABC5qmYiLEoXhYm07/Vy\n O6BT5bLYwsB10iKOH4bdgAUAkVEuZhLKr9I7dzrXOpk2I9F4yrNoRVKf5Vi8=","X-Gm-Gg":"AeBDieud/qFr26bvVQ22+wNUsroeGtl3OCcgyyyhsmnn+FOXuLWa0Go7A4wlI8lvaLO\n gYNc4cRU6mtAlRbPPu42/3DV8M3fuTnfb37WB52Wlxu/jWkfp8IjhHiKssmw/qI3h6DFX1ugtYe\n 8NxOS+W4nwrAES5MhYTJ+T9GR1ytOP2BJhCzdq8aH3wmp65x77PzJeisGuYyiYMdBx0kR2EcvuB\n iJ3GM+o5/Q4oqDqgvz3PC5UjsgaBOFvjzDmUyMuytE8Dlzkp9+V2u65/OIneq1j9MF+4je7i1rZ\n /71TpBgj/6KF41xQGw1W8r1R9JvqDHUz/SGXHfhYgrSvfPwh/xdjOHKHcqheZ4ETKLpvYN4Im2T\n w/1iaz8ejQKdICjM=","X-Received":["by 2002:a05:690e:168c:b0:654:5290:b34b with SMTP id\n 956f58d0204a3-6545290ceddmr6460441d50.12.1776954108498;\n Thu, 23 Apr 2026 07:21:48 -0700 (PDT)","by 2002:a05:690e:168c:b0:654:5290:b34b with SMTP id\n 956f58d0204a3-6545290ceddmr6460402d50.12.1776954107850;\n Thu, 23 Apr 2026 07:21:47 -0700 (PDT)"],"Date":"Thu, 23 Apr 2026 10:21:44 -0400","From":"Marek Polacek ","To":"Patrick Palka ","Cc":"GCC Patches , Jason Merrill ,\n Jakub Jelinek ","Subject":"Re: [PATCH] c++/reflection: erroneous access check on dependent\n splice [PR124989]","Message-ID":"","References":"<20260422220620.2017820-1-polacek@redhat.com>\n <13166c64-8c75-f508-35ca-30d2f60cef10@idea>","MIME-Version":"1.0","In-Reply-To":"<13166c64-8c75-f508-35ca-30d2f60cef10@idea>","User-Agent":"Mutt/2.3.1 (2026-03-20)","X-Mimecast-Spam-Score":"0","X-Mimecast-MFC-PROC-ID":"gv9aSZXlAAxpO5XPKmJjm4RyNoAMscosfwpV8iNgHsA_1776954108","X-Mimecast-Originator":"redhat.com","Content-Type":"text/plain; charset=us-ascii","Content-Disposition":"inline","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"}}]