Message ID | 20230403144932.747134-1-ppalka@redhat.com |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2358699vqo; Mon, 3 Apr 2023 07:50:23 -0700 (PDT) X-Google-Smtp-Source: AKy350ak9qdPs0CNV7fNRKzlL1rtZjYRsTZHgValoQBNT/bAbB887OEQYnHMPKIcWYj1/PQYYIDk X-Received: by 2002:a17:907:2c46:b0:879:ab3:93d1 with SMTP id hf6-20020a1709072c4600b008790ab393d1mr39357688ejc.4.1680533423226; Mon, 03 Apr 2023 07:50:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680533423; cv=none; d=google.com; s=arc-20160816; b=BwlyWlfxVq0GI1bZHlX+qU/TszbSWIwHgnNTLQyqYTER4+EasPbxNFYqoO27GVkCDE H4D2Uyh5iwHhFRo3Y2byzXmmNI1cjSNPPgVXyrDm8l/jKrQ9Xvnn1hkwQwTiXwAVHxn+ /imDYoxqh22qdx5Mr1QzbupoTeGQBdXvpdT3zd/KtQpWInzAt8WrK1plTSmUoSlV/WjA mDROpaz+vcQ3rWqOu3ICtKQzNONb4TPWYrpV1+Q9VzGovZiLQdIYztoEOURx7xjCVu/V pIyobBU8o8pKCbFhVH4NKyVG8uj+slYewU9swQ3JX4J3kV27mMs4rPl5Pyd1UKHOvFkI mw0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:message-id:date:subject:cc :to:dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=DNDrDW8qvR2lGaishxjyG1m0h46FQ5tX6dGE94LmP9I=; b=TUUvEaRsv/DYhMrU7ZuPB/MPMy523xphplqbyZuxUj0cXsS4wKEOY7lViyrFbPUu/k 7xPThp0hyAnHLWdSui2jC7PVJBTkz6PFTkKXSXSxTiHaiBJO80e9BCuZzpKNXIQRIKNW 6zR/ipmdnBr+uh0XwMJZGN0ZVb0vleDY9AQN1BflylMRLSvgF1F4cnRyCY3q2ni4Y5OU x254/SOJ36E8JgIgrIQEFcLaFopparvBpTFbjM4l7wnoiQdU9BleZ6YdjHXVUGqCkAk9 gtOSOjfgao+gdVWgN7neMPOnUAsSgCJ8Wm732DutfaYj2togfcxpKWskMPj5puKCv/8j kwJg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=Poozp+x4; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id m23-20020aa7c497000000b004fd16f5aa1bsi6330833edq.103.2023.04.03.07.50.22 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Apr 2023 07:50:23 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=Poozp+x4; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 228DF3858D39 for <ouuuleilei@gmail.com>; Mon, 3 Apr 2023 14:50:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 228DF3858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680533422; bh=DNDrDW8qvR2lGaishxjyG1m0h46FQ5tX6dGE94LmP9I=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=Poozp+x4oWTjCHwTVluRRsO/BLDK+uxoGDaNEwZ92wRwtx2ysf95y7DUARyqXuxnZ yT21qCaLIWI3SfoBm3w9eyGwWjpCdODmblrOTSkTFCT3fCoTq6K2hfKF5OFA178JyF CVjNhDWbRkAZTRI1LSaP9BMWg0o2eH/F0SRjzMMQ= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id BF2A63858D39 for <gcc-patches@gcc.gnu.org>; Mon, 3 Apr 2023 14:49:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF2A63858D39 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-478-ZokfslTPOCOStqxoh8PDQw-1; Mon, 03 Apr 2023 10:49:37 -0400 X-MC-Unique: ZokfslTPOCOStqxoh8PDQw-1 Received: by mail-qt1-f197.google.com with SMTP id h6-20020ac85846000000b003e3c23d562aso19968506qth.1 for <gcc-patches@gcc.gnu.org>; Mon, 03 Apr 2023 07:49:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680533376; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DNDrDW8qvR2lGaishxjyG1m0h46FQ5tX6dGE94LmP9I=; b=5kbqV1frZekgcE9/W4t37HGAeRsgwHylkgOn976qkB3j520FEEN5iSQC6D2Fhz5SfR KvuafQj62362h+oOfN0hxGR2ciYRAw0gfNU48CoQ2ZNIXnsxYBATDXdfpeJG6DvDqKq3 M3hAyheagoVZJha7Hy1dqxKEyY56t7fnXERExKw3uSPA3PMVgEy2GBHLN0lZOSDQL/3K tFnKoEr8UUFLlvbJYtytTq2Le+0lQ9cbMXP6rBFeWTXLaA3a0aI54ZJvK51/eqLEXhr5 CHr9jtB7lRHwYZHGC4IKGH88j4ihpRGgeUy02dM5yg42aZhDdR3OcmrimyMo1KOVQ9R8 NPfg== X-Gm-Message-State: AAQBX9c1WzqU7NIZkgp/GVxDb+5y/TmC0UGjbO6kzP4ewDN7y2UltLJi iBqV7sVfzJvQ2SvIWBhx4X4M91X601n5SLmNWEdjR1G9aBC6xoXYXzne9Gh+N+vTRj0YklRSR+Y B/DNwYX8T/30/bDDfM1m+g5TCHy6xl1fdsHbKEBT7Iljp4kV71jBvzdakiorttLzwneFgsfM/RS s= X-Received: by 2002:a05:6214:29e1:b0:5d1:d9f3:dd8c with SMTP id jv1-20020a05621429e100b005d1d9f3dd8cmr55424024qvb.46.1680533375964; Mon, 03 Apr 2023 07:49:35 -0700 (PDT) X-Received: by 2002:a05:6214:29e1:b0:5d1:d9f3:dd8c with SMTP id jv1-20020a05621429e100b005d1d9f3dd8cmr55423986qvb.46.1680533375566; Mon, 03 Apr 2023 07:49:35 -0700 (PDT) Received: from localhost.localdomain (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id o8-20020a0cc388000000b005dd8b93457dsm2661213qvi.21.2023.04.03.07.49.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Apr 2023 07:49:35 -0700 (PDT) To: gcc-patches@gcc.gnu.org Cc: jason@redhat.com, Patrick Palka <ppalka@redhat.com> Subject: [PATCH] c++: satisfaction and ARGUMENT_PACK_SELECT [PR105644] Date: Mon, 3 Apr 2023 10:49:32 -0400 Message-Id: <20230403144932.747134-1-ppalka@redhat.com> X-Mailer: git-send-email 2.40.0.153.g6369acd968 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-13.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Patrick Palka via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Patrick Palka <ppalka@redhat.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762167014889254104?= X-GMAIL-MSGID: =?utf-8?q?1762167014889254104?= |
Series |
c++: satisfaction and ARGUMENT_PACK_SELECT [PR105644]
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
Patrick Palka
April 3, 2023, 2:49 p.m. UTC
This testcase demonstrates we can legitimately enter satisfaction with an ARGUMENT_PACK_SELECT argument, which is problematic because we can't store such arguments in the satisfaction cache (or any other hash table). Since this appears to be possible only during constrained auto deduction for a return-type-requirement, the most appropriate spot to fix this seems to be from do_auto_deduction, by calling preserve_args to strip A_P_S args before entering satisfaction. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/12? PR c++/105644 gcc/cp/ChangeLog: * pt.cc (do_auto_deduction): Call preserve_args before entering satisfaction for adc_requirement contexts. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires36.C: New test. --- gcc/cp/pt.cc | 6 ++++++ gcc/testsuite/g++.dg/cpp2a/concepts-requires36.C | 12 ++++++++++++ 2 files changed, 18 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-requires36.C
Comments
On 4/3/23 10:49, Patrick Palka wrote: > This testcase demonstrates we can legitimately enter satisfaction with > an ARGUMENT_PACK_SELECT argument, which is problematic because we can't > store such arguments in the satisfaction cache (or any other hash table). > > Since this appears to be possible only during constrained auto deduction > for a return-type-requirement, the most appropriate spot to fix this seems > to be from do_auto_deduction, by calling preserve_args to strip A_P_S args > before entering satisfaction. > > +++ b/gcc/cp/pt.cc > @@ -30965,6 +30965,12 @@ do_auto_deduction (tree type, tree init, tree auto_node, > return type; > } > > + /* We can see an ARGUMENT_PACK_SELECT argument when evaluating > + a return-type-requirement. Get rid of them before entering > + satisfaction, since the satisfaction cache can't handle them. */ > + if (context == adc_requirement) > + outer_targs = preserve_args (outer_targs); I'd like to get do_auto_deduction out of the business of handling return-type-requirements, since there is no longer any actual deduction involved (as there was in the TS). So I'd prefer not to add any more tweaks there. Maybe this should happen higher up, in tsubst_requires_expr? Maybe just before the call to add_extra_args? Jason
On Mon, 3 Apr 2023, Jason Merrill wrote: > On 4/3/23 10:49, Patrick Palka wrote: > > This testcase demonstrates we can legitimately enter satisfaction with > > an ARGUMENT_PACK_SELECT argument, which is problematic because we can't > > store such arguments in the satisfaction cache (or any other hash table). > > > > Since this appears to be possible only during constrained auto deduction > > for a return-type-requirement, the most appropriate spot to fix this seems > > to be from do_auto_deduction, by calling preserve_args to strip A_P_S args > > before entering satisfaction. > > > > +++ b/gcc/cp/pt.cc > > @@ -30965,6 +30965,12 @@ do_auto_deduction (tree type, tree init, tree > > auto_node, > > return type; > > } > > + /* We can see an ARGUMENT_PACK_SELECT argument when evaluating > > + a return-type-requirement. Get rid of them before entering > > + satisfaction, since the satisfaction cache can't handle them. */ > > + if (context == adc_requirement) > > + outer_targs = preserve_args (outer_targs); > > I'd like to get do_auto_deduction out of the business of handling > return-type-requirements, since there is no longer any actual deduction > involved (as there was in the TS). So I'd prefer not to add any more tweaks > there. > > Maybe this should happen higher up, in tsubst_requires_expr? Maybe just > before the call to add_extra_args? Interestingly, calling preserve_args from tsubst_requires_expr breaks cases where a requires-expression contains an inner pack expansion over the same pack as the outer expansion, such as 'Ts... ts' in template<class... Ts> concept C = (requires (Ts... ts) { Ts(); } && ...); static_assert(C<int, char>); and 'sizeof...(Ts)' in template<int> struct A; template<class... Ts> concept C = (requires { typename A<sizeof...(Ts)>; } && ...); static_assert(C<int, char>); because we need to hold on to the ARGUMENT_PACK_SELECT version of the argument in order to properly substitute 'Ts... ts' and 'sizeof...(Ts)' during each outer expansion, but calling preserve_args gets rid of the A_P_S. And on second thought, narrowly calling preserve_args from do_auto_deduction (or type_deducible_p) isn't quite correct either, consider: template<class T, class U, int N> concept C = __is_same(T, U) && N > 1; template<class... Ts> concept D = (requires { { Ts() } -> C<Ts, sizeof...(Ts)>; } && ...); static_assert(D<int, char>); We need to hold on to the A_P_S in order to check the return-type-requirement C<Ts, sizeof...(Ts)>, but the satisfaction cache can't handle A_P_S! The following non-requires-expr version of that example works: template<class T, class U, int N> concept C = __is_same(T, U) && N > 1; template<class... Ts> concept D = (C<Ts, Ts, sizeof...(Ts)> && ...); static_assert(D<int, char>); because here we directly substitute into the concept-id C<Ts, Ts, sizeof...(Ts)>, so we effectively end up checking satisfaction of C<int, int, 2> and C<char, char, 2> directly and never enter satisfaction with an A_P_S argument. So ISTM the satisfaction cache might need to be able to cache A_P_S arguments perhaps by changing preserve_args to instead make a copy of each A_P_S and set a flag on this copy to indicate it's "stable" and therefore suitable for hashing etc.
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc index 4429ae66b68..821e0035c08 100644 --- a/gcc/cp/pt.cc +++ b/gcc/cp/pt.cc @@ -30965,6 +30965,12 @@ do_auto_deduction (tree type, tree init, tree auto_node, return type; } + /* We can see an ARGUMENT_PACK_SELECT argument when evaluating + a return-type-requirement. Get rid of them before entering + satisfaction, since the satisfaction cache can't handle them. */ + if (context == adc_requirement) + outer_targs = preserve_args (outer_targs); + if (context == adc_return_type || context == adc_variable_type || context == adc_decomp_type) diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-requires36.C b/gcc/testsuite/g++.dg/cpp2a/concepts-requires36.C new file mode 100644 index 00000000000..7d13b9b3e54 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-requires36.C @@ -0,0 +1,12 @@ +// PR c++/105644 +// { dg-do compile { target c++20 } } + +template<class T, class U> +concept same_as = __is_same(T, U); + +template<class... Ts> +concept C = (requires { { Ts() } -> same_as<Ts>; } && ...); + +static_assert(C<int, char>); +static_assert(!C<int, const char>); +static_assert(!C<const int, char>);