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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 766C03858D28 for ; Mon, 25 Apr 2022 21:53:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 766C03858D28 Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-53-675w8syuM6y71Xrd_eMscA-1; Mon, 25 Apr 2022 17:53:50 -0400 X-MC-Unique: 675w8syuM6y71Xrd_eMscA-1 Received: by mail-qt1-f199.google.com with SMTP id a25-20020ac844b9000000b002f1f8988487so8721947qto.17 for ; Mon, 25 Apr 2022 14:53:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3qiTAPgMy+uSY29krVZUXVouMFjUKMhDcZk1hgRW4H8=; b=pUxku2CO8ma54mx+BXFVZFoyJWr5LigmnaeyMqsJrY+XJC/Q4YHsiHZvhju9Tusu57 c0RbK1LWTdZuBlEUjxWs/rxBlINabjpyJq85O+Cj+RUVfEDulrzvSdYZ2B6ltHNuL5Gt tEV7DpSOjbLxv+B2oHyC4T60XKKNqyb9fDdLB1uQxUwTl61hUDrF/piMRXgao2dGrYar anTFW8U/7+qn9usdNqCsaN+MR7xIrKqcwIYFw9I1yEeBnxPzpykau3NhL7gcxTNPC5jG +Nj25RU5muCVUR3dww0RmXVX8/VEWO0tI9J18xU4493dYPtu2phzmIDfUXlGC5qjy3ST FJew== X-Gm-Message-State: AOAM532rU66BUtwCHWtu+Q34BUv9WVdQuw6KWOr89f5KQXhoBEMYSWjQ cfXqEu8Wj8DkOXbpKA3snpXfW+MzeLTGCT0Yh1ckxIMnVOzwuxT7DlS5i18Oh6vHuDy0/Ragryf pO0K/QLILs53A9idITQ== X-Received: by 2002:a05:620a:b4a:b0:69f:66fc:a3db with SMTP id x10-20020a05620a0b4a00b0069f66fca3dbmr2645442qkg.679.1650923629782; Mon, 25 Apr 2022 14:53:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+ofKXk2uKHtKojKWwawe5g/E4m+K+2yLEJcbj7jVREv4K6zrgcorAXOeUxopXZFps4Oen2w== X-Received: by 2002:a05:620a:b4a:b0:69f:66fc:a3db with SMTP id x10-20020a05620a0b4a00b0069f66fca3dbmr2645433qkg.679.1650923629438; Mon, 25 Apr 2022 14:53:49 -0700 (PDT) Received: from [192.168.1.100] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id c20-20020a05622a059400b002e1d59e68f3sm7137543qtb.48.2022.04.25.14.53.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Apr 2022 14:53:48 -0700 (PDT) Message-ID: <2d167c8c-44aa-93b5-c690-ad404bd85c83@redhat.com> Date: Mon, 25 Apr 2022 17:53:47 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH] c++: partial ordering with dependent NTTP type [PR105289] To: Patrick Palka Cc: gcc-patches@gcc.gnu.org References: <20220422175032.3106274-1-ppalka@redhat.com> <6292a77d-f373-4158-036d-9a56e599bccf@idea> <790feed1-0d96-4276-fdc8-f3d11368ec94@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, 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: Mon, 25 Apr 2022 21:53:54 -0000 On 4/25/22 14:10, Patrick Palka wrote: > On Mon, 25 Apr 2022, Jason Merrill wrote: > >> On 4/22/22 15:27, Patrick Palka wrote: >>> On Fri, 22 Apr 2022, Patrick Palka wrote: >>> >>>> Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing >>>> (respectively) on two testcases that we used to accept in C++17 mode. >>>> Both testcases declare partial specializations for which the primary >>>> template contains an NTTP with dependent type, but the correctness of >>>> these partial specializations is unclear according to PR86193. >>>> >>>> This patch restores the previous C++17 behavior for such partial >>>> specializations by restricting the r11-6483 change to just ordinary >>>> deduction as opposed to deduction for sake of partial ordering. >>> >>> Note that if we're okay with rejecting such partial specializations even >>> in C++17 mode (and thus deeming PR105289 to be ICE-on-invalid instead of >>> ICE-on-valid), then the fix for the reported ICE is just: >>> >>> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc >>> index dde62ee052d..6d65f6ad3cf 100644 >>> --- a/gcc/cp/pt.cc >>> +++ b/gcc/cp/pt.cc >>> @@ -24299,7 +24299,7 @@ unify (tree tparms, tree targs, tree parm, tree arg, >>> int strict, >>> /* Now check whether the type of this parameter is still >>> dependent, and give up if so. */ >>> ++processing_template_decl; >>> - tparm = tsubst (tparm, targs, tf_none, NULL_TREE); >>> + tparm = tsubst (TREE_TYPE (parm), targs, tf_none, NULL_TREE); >>> --processing_template_decl; >>> if (uses_template_parms (tparm)) >>> return unify_success (explain_p); >>> >>> i.e. we need to substitute into the original NTTP type, not into the >>> already substituted NTTP type. >> >> I'm happy rejecting partial-specialization12.C on that basis. 11 is >> interesting because int is a non-dependent type; it might be worth adding that >> testcase to the DR455 discussion. >> >> I think let's go with this patch and bump down the "partial specialization >> isn't more specialized" diagnostic from permerror to on-by-default pedwarn. > > Ah, sounds good to me. like so? > > -- >8 -- > > Subject: [PATCH] c++: partial ordering with dependent NTTP type [PR105289] > > Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing > on (respectively) two testcases that we used to accept in C++17 mode > since r8-1437-g3da557ec145823. Both testcases declare a partial > specialization for which the primary template contains an NTTP with > dependent type, but the validity of these partial specializations is > unclear and is the subject of PR86193 / CWG 455. > > This patch just fixes the reported ICE in the second testcase. The bug > was that when checking whether the type of an NTTP uses still-undeduced > parameters, we'd substitute into the previously substituted NTTP type > instead of into the original NTTP type. > > And given that the treatment of such partial specializations seems to > be underspecified in the standard, this patch downgrades the general > "not more specialized" diagnostic from a permerror to a pedwarn. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/11? OK. > PR c++/105289 > PR c++/86193 > > gcc/cp/ChangeLog: > > * pt.cc (process_partial_specialization): Downgrade "partial > specialization isn't more specialized" diagnostic from permerror > to an on-by-default pedwarn. > (unify) : When substituting into the > NTTP type a second time, use the original type not the > substituted type. > > gcc/testsuite/ChangeLog: > > * g++.dg/template/partial-specialization11.C: New test. > * g++.dg/template/partial-specialization12.C: New test. > --- > gcc/cp/pt.cc | 7 ++++--- > .../g++.dg/template/partial-specialization11.C | 11 +++++++++++ > .../g++.dg/template/partial-specialization12.C | 13 +++++++++++++ > 3 files changed, 28 insertions(+), 3 deletions(-) > create mode 100644 gcc/testsuite/g++.dg/template/partial-specialization11.C > create mode 100644 gcc/testsuite/g++.dg/template/partial-specialization12.C > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > index dde62ee052d..7dd9e6788f4 100644 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -5227,8 +5227,9 @@ process_partial_specialization (tree decl) > && !get_partial_spec_bindings (maintmpl, maintmpl, specargs)) > { > auto_diagnostic_group d; > - if (permerror (input_location, "partial specialization %qD is not " > - "more specialized than", decl)) > + if (pedwarn (input_location, 0, > + "partial specialization %qD is not more specialized than", > + decl)) > inform (DECL_SOURCE_LOCATION (maintmpl), "primary template %qD", > maintmpl); > } > @@ -24299,7 +24300,7 @@ unify (tree tparms, tree targs, tree parm, tree arg, int strict, > /* Now check whether the type of this parameter is still > dependent, and give up if so. */ > ++processing_template_decl; > - tparm = tsubst (tparm, targs, tf_none, NULL_TREE); > + tparm = tsubst (TREE_TYPE (parm), targs, tf_none, NULL_TREE); > --processing_template_decl; > if (uses_template_parms (tparm)) > return unify_success (explain_p); > diff --git a/gcc/testsuite/g++.dg/template/partial-specialization11.C b/gcc/testsuite/g++.dg/template/partial-specialization11.C > new file mode 100644 > index 00000000000..df1ead380f1 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/template/partial-specialization11.C > @@ -0,0 +1,11 @@ > +// PR c++/86193 > +// CWG 455 (active) > +// { dg-options "" } // clear -pedantic-errors > + > +template struct value_type; > + > +template::type V> > +struct push_front_vlist; > + > +template > +struct push_front_vlist { }; // { dg-warning "not more specialized" } > diff --git a/gcc/testsuite/g++.dg/template/partial-specialization12.C b/gcc/testsuite/g++.dg/template/partial-specialization12.C > new file mode 100644 > index 00000000000..6e84f4949c1 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/template/partial-specialization12.C > @@ -0,0 +1,13 @@ > +// PR c++/105289 > +// PR c++/86193 > +// CWG 455 (active) > +// { dg-do compile { target c++11 } } > + > +template > +struct value_type; > + > +template ::type Element> > +struct push_front_vlist; > + > +template