From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 40C543857830 for ; Fri, 1 Oct 2021 17:29:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40C543857830 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-549-QGQzb113N1CV9n8IoDDWtA-1; Fri, 01 Oct 2021 13:29:57 -0400 X-MC-Unique: QGQzb113N1CV9n8IoDDWtA-1 Received: by mail-qt1-f197.google.com with SMTP id h10-20020ac8584a000000b002a712bc435fso7510837qth.20 for ; Fri, 01 Oct 2021 10:29:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=hnDTgLWilWR5P8q6wXo9eK3751Wh9d7M2Qw8zCMoqu4=; b=La/NcCrV38OzDnf1vJZRaFxxxEJd97+SXqGMUYNfzFrQV3SofGRxZwaj5EjH6gj2cv baD16xVO8lPZ+9lGTIXvmhoTn0fB/cRFpDTbdMb9tfKCpoM6DTtMCYdRnqM9q02TIKMA z1cfYUtRM9XAGF0tz1TJzERdp90g8e0hBUsmTmYOlC8p5CUbfclJtJ0VjtWA7WgsKdA6 xin5X2SsiOh3RuAMFfh9nN+Zyvzqj5tF0KrQ9WOLoNcSvv7TtTwENymVKfqZx18hgykD UnmX6YLvQSzd5UoHZH8Jy2uFPIDwKsml6JBSjBHO+MiMJAZQjVAUp+dqKA1XqF2p5oMT GbWg== X-Gm-Message-State: AOAM532IyxRB0nREG22H2STvZ7a11nWCstPUxxvm91tcXGnQz1pqSc4W cNfNH4OBNQ2ig3jzcdBRgmE00bMM4mtWtjGhMHmkZy7rDrq47+yEkuPKN8g+2dkBFDZzylHJfBY 91FPa8Jvp1jxRgzf/Ig== X-Received: by 2002:a0c:aa97:: with SMTP id f23mr4365437qvb.49.1633109396518; Fri, 01 Oct 2021 10:29:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy6+s9r2U+Ql6IvR15ZIY9CS769S2hvHowpFfA//0rf76K2TAr6s15sJ+25zJ4uTz2omvrB7g== X-Received: by 2002:a0c:aa97:: with SMTP id f23mr4365418qvb.49.1633109396237; Fri, 01 Oct 2021 10:29:56 -0700 (PDT) Received: from [192.168.1.130] (ool-457d493a.dyn.optonline.net. [69.125.73.58]) by smtp.gmail.com with ESMTPSA id c1sm3332623qka.128.2021.10.01.10.29.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Oct 2021 10:29:55 -0700 (PDT) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Fri, 1 Oct 2021 13:29:55 -0400 (EDT) To: Jason Merrill cc: Patrick Palka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c++: unifying equal NONTYPE_ARGUMENT_PACKs [PR102547] In-Reply-To: <8a30a9f4-911b-94f9-680c-0dbb3ba8a7be@redhat.com> Message-ID: <5ffff065-a952-558b-30b4-3cb2bac29f32@idea> References: <20211001134643.1941700-1-ppalka@redhat.com> <0e9e4c2f-aadc-6358-72de-a5f3620ebad9@redhat.com> <2ac834ad-fd22-a6be-7bba-ac9badbb484@idea> <8a30a9f4-911b-94f9-680c-0dbb3ba8a7be@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-15.9 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_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2021 17:30:04 -0000 On Fri, 1 Oct 2021, Jason Merrill wrote: > On 10/1/21 10:26, Patrick Palka wrote: > > On Fri, 1 Oct 2021, Jason Merrill wrote: > > > > > On 10/1/21 09:46, Patrick Palka wrote: > > > > Here during partial ordering of the two partial specializations we end > > > > up in unify with parm=arg=NONTYPE_ARGUMENT_PACK, and crash > > > > shortly > > > > thereafter because uses_template_parms calls > > > > potential_constant_expression > > > > which doesn't handle NONTYPE_ARGUMENT_PACK. > > > > > > > > This patch fixes this by checking dependent_template_arg_p instead of > > > > uses_template_parms when parm==arg, which does handle > > > > NONTYPE_ARGUMENT_PACK. > > > > We could also perhaps fix uses_template_parms / inst_dep_expr_p to > > > > better > > > > handle NONTYPE_ARGUMENT_PACK, > > > > > > Please. > > > > Sounds good, like the following then? Passes light testing, bootstrap > > and regtest on progress. > > > > -- >8 -- > > > > PR c++/102547 > > > > gcc/cp/ChangeLog: > > > > * pt.c (instantiation_dependent_expression_p): Sidestep checking > > potential_constant_expression on NONTYPE_ARGUMENT_PACK. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/cpp0x/variadic-partial2.C: New test. > > * g++.dg/cpp0x/variadic-partial2a.C: New test. > > --- > > gcc/cp/pt.c | 4 +++- > > .../g++.dg/cpp0x/variadic-partial2.C | 16 ++++++++++++++ > > .../g++.dg/cpp0x/variadic-partial2a.C | 22 +++++++++++++++++++ > > 3 files changed, 41 insertions(+), 1 deletion(-) > > create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C > > create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C > > > > diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c > > index 1dcdffe322a..643204103c5 100644 > > --- a/gcc/cp/pt.c > > +++ b/gcc/cp/pt.c > > @@ -27705,7 +27705,9 @@ instantiation_dependent_expression_p (tree > > expression) > > { > > return (instantiation_dependent_uneval_expression_p (expression) > > || (processing_template_decl > > - && potential_constant_expression (expression) > > + && expression != NULL_TREE > > + && (TREE_CODE (expression) == NONTYPE_ARGUMENT_PACK > > + || potential_constant_expression (expression)) > > I'd prefer to loop over the elements of the pack, either here or (probably > better) in potential_constant_expression. Ah, makes sense. Like so? Bootstrapped and regtested on x86_64-pc-linux-gnu. -- >8 -- Subject: [PATCH] c++: unifying equal NONTYPE_ARGUMENT_PACKs [PR102547] Here during partial ordering of the two partial specializations we end up in unify with parm=arg=NONTYPE_ARGUMENT_PACK, and crash shortly thereafter because uses_template_parms(parms) calls potential_const_expr which doesn't handle NONTYPE_ARGUMENT_PACK. This patch fixes this by extending potential_constant_expression to handle NONTYPE_ARGUMENT_PACK appropriately. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/11? PR c++/102547 gcc/cp/ChangeLog: * constexpr.c (potential_constant_expression_1): Handle NONTYPE_ARGUMENT_PACK. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-partial2.C: New test. * g++.dg/cpp0x/variadic-partial2a.C: New test. --- gcc/cp/constexpr.c | 10 +++++++++ .../g++.dg/cpp0x/variadic-partial2.C | 16 ++++++++++++++ .../g++.dg/cpp0x/variadic-partial2a.C | 22 +++++++++++++++++++ 3 files changed, 48 insertions(+) create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C create mode 100644 gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c index 18d9d117a48..e95ff00774f 100644 --- a/gcc/cp/constexpr.c +++ b/gcc/cp/constexpr.c @@ -9043,6 +9043,16 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict, bool now, case CO_RETURN_EXPR: return false; + case NONTYPE_ARGUMENT_PACK: + { + tree args = ARGUMENT_PACK_ARGS (t); + int len = TREE_VEC_LENGTH (args); + for (int i = 0; i < len; ++i) + if (!RECUR (TREE_VEC_ELT (args, i), any)) + return false; + return true; + } + default: if (objc_non_constant_expr_p (t)) return false; diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C b/gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C new file mode 100644 index 00000000000..df61f26a3c1 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/variadic-partial2.C @@ -0,0 +1,16 @@ +// PR c++/102547 +// { dg-do compile { target c++11 } } + +template +struct vals { }; + +template +struct vals_client { }; + +template +struct vals_client, T> { }; + +template +struct vals_client, void> { }; + +template struct vals_client, void>; //- "sorry, unimplemented..., ICE" diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C b/gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C new file mode 100644 index 00000000000..e98bdbbc07b --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/variadic-partial2a.C @@ -0,0 +1,22 @@ +// PR c++/102547 +// { dg-do compile { target c++11 } } +// A version of variadic-partial2.C where partial ordering is performed +// on function templates instead of class templates. + +template +struct vals { }; + +template +void f(V, T) { }; + +template +void f(vals, T) { }; + +template +void f(vals, char) { }; + +template void f(vals<1, 2>, char); //- "sorry, unimplemented..., ICE" + +int main() { + f(vals<1, 3>{}, 'a'); //- "sorry, unimplemented..., ICE" +} -- 2.33.0.610.gcefe983a32