Message ID | 20220601182013.2193209-1-ppalka@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4F34F3836E7E for <patchwork@sourceware.org>; Wed, 1 Jun 2022 18:20:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4F34F3836E7E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1654107649; bh=m0+r429NlCKybPzCYT9G9Lr6ZClbeABbgrpHe92OPA4=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=sKgVlpjLR0y2hTn3rNfIK4db05RzI/ASH5N8llir4bWhh+ClgoASd2z4FedfHgRmc UtxGGj20JF8x8vdz3c2yzMQY8kuY894PoemBtM/AYkFoA+XiSkZgiVLGMke163KHWn cGGz9TRRBVGZxTwmV82lxLVEr+7tNjFb+NuBT/rI= 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.129.124]) by sourceware.org (Postfix) with ESMTPS id C73EF384B0C9 for <gcc-patches@gcc.gnu.org>; Wed, 1 Jun 2022 18:20:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C73EF384B0C9 Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-373-phIJIBCSPnqJEee0vgYptg-1; Wed, 01 Jun 2022 14:20:16 -0400 X-MC-Unique: phIJIBCSPnqJEee0vgYptg-1 Received: by mail-qv1-f72.google.com with SMTP id bv14-20020ad4488e000000b004646673e80bso1908642qvb.23 for <gcc-patches@gcc.gnu.org>; Wed, 01 Jun 2022 11:20:16 -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:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=m0+r429NlCKybPzCYT9G9Lr6ZClbeABbgrpHe92OPA4=; b=fjzEzCj5hDsKSF3Ydx3+cgokAWfMfMCne2mWzCO4H15hk/et9XWGqPoaxdIK8Rw8ST FUKZdbQYXI1iBr9uASPEf8NoYNkBD3LhXAN4IeSOPfuePpNOxfLDlKXAVgUbmVMJFPdx sIZm+GJGDXSGG+wx7220XEBX1n2sVah/4cjKilWuZIaNJdxuszlouLYAVUqcxIWDQJBK jFa4c7xMrgRZ8lHUmBk7LAu4MDJaR0qhPG3pU5TZ9KzaA5eSZHU5U5rpqlmRkFsr/sOL m7Q7qyBQ2zPEg8Bk6y/HjjbbIF3/d/UWQwGtsf9vNHXR74Qbd0d5raH3pN8GAKjllg/V HvVw== X-Gm-Message-State: AOAM530FOR5yOhcwrvsW/MCZDg8R7N7Sk1fW/xYHlTiUL+6lDNTkdzQa R8EjWS4kmJqiRU1qALIU1pMR6gxixQN6ZbBWT8vqGGsYpHm7GeLimZFYoyMcqHo49f5aHCvterN p4FIPbpBnIgbz+QRuxLD92Gtm8kRHQ74sBWhp/VtAPqmKJzdbPzC6YhGbgLDS0nVcugc= X-Received: by 2002:ac8:7d4e:0:b0:2f9:f97:2258 with SMTP id h14-20020ac87d4e000000b002f90f972258mr803188qtb.355.1654107615685; Wed, 01 Jun 2022 11:20:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw3mtnWxB0ZUMObpKyiBuuu9NhQB2e06qadqb0herfaA+PdqwftKnfKfl0SpSAif7kS6EEUVg== X-Received: by 2002:ac8:7d4e:0:b0:2f9:f97:2258 with SMTP id h14-20020ac87d4e000000b002f90f972258mr803158qtb.355.1654107615358; Wed, 01 Jun 2022 11:20:15 -0700 (PDT) Received: from localhost.localdomain (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id i12-20020a05622a08cc00b002fafd1643d0sm1528017qte.8.2022.06.01.11.20.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 11:20:15 -0700 (PDT) To: gcc-patches@gcc.gnu.org Subject: [PATCH] c++: value-dep but not type-dep decltype operand [PR105756] Date: Wed, 1 Jun 2022 14:20:13 -0400 Message-Id: <20220601182013.2193209-1-ppalka@redhat.com> X-Mailer: git-send-email 2.36.1.203.g1bcf4f6271 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=-14.2 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, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
c++: value-dep but not type-dep decltype operand [PR105756]
|
|
Commit Message
Patrick Palka
June 1, 2022, 6:20 p.m. UTC
r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent decltype operands by relaxing instantiate_non_dependent_expr to check instantiation_dependent_uneval_expression_p. But as the testcase below demonstrates, this predicate is too permissive here because it allows value-dependent-only expressions to go through and get instantiated ahead of time, which causes us to crash during constexpr evaluation of (5 % N). This patch strengthens instantiate_non_dependent_expr to use the non-uneval version of the predicate instead, which does consider value dependence. In turn, we need to make finish_decltype_type avoid calling i_n_d_e on a value-dependent-only expression; I assume we still want to resolve the decltype ahead of time in this case. (Doing so seems unintuitive to me since the expression could be ill-formed at instantiation time as in the testcase, but it matches the behavior of Clang and MSVC.) Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/12? PR c++/105756 gcc/cp/ChangeLog: * pt.cc (instantiate_non_dependent_expr_internal): Adjust comment. (instantiate_non_dependent_expr_sfinae): Assert i_d_e_p instead of i_d_u_e_p. * semantics.cc (finish_decltype_type): Don't instantiate the expression when i_d_e_p is true. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/decltype82.C: New test. --- gcc/cp/pt.cc | 4 ++-- gcc/cp/semantics.cc | 13 ++++++++++++- gcc/testsuite/g++.dg/cpp0x/decltype82.C | 10 ++++++++++ 3 files changed, 24 insertions(+), 3 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82.C
Comments
On 6/1/22 14:20, Patrick Palka wrote: > r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent > decltype operands by relaxing instantiate_non_dependent_expr to check > instantiation_dependent_uneval_expression_p. But as the testcase below > demonstrates, this predicate is too permissive here because it allows > value-dependent-only expressions to go through and get instantiated > ahead of time, which causes us to crash during constexpr evaluation of > (5 % N). Why are we doing constexpr evaluation in unevaluated context? > This patch strengthens instantiate_non_dependent_expr to use the > non-uneval version of the predicate instead, which does consider value > dependence. In turn, we need to make finish_decltype_type avoid calling > i_n_d_e on a value-dependent-only expression; I assume we still want to > resolve the decltype ahead of time in this case. (Doing so seems > unintuitive to me since the expression could be ill-formed at > instantiation time as in the testcase, but it matches the behavior of > Clang and MSVC.) I don't think there's any problem with the testcase; decltype(1/0) is well-formed because the expression is not evaluated. > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/12? > > PR c++/105756 > > gcc/cp/ChangeLog: > > * pt.cc (instantiate_non_dependent_expr_internal): Adjust > comment. > (instantiate_non_dependent_expr_sfinae): Assert i_d_e_p instead > of i_d_u_e_p. > * semantics.cc (finish_decltype_type): Don't instantiate the > expression when i_d_e_p is true. > > gcc/testsuite/ChangeLog: > > * g++.dg/cpp0x/decltype82.C: New test. > --- > gcc/cp/pt.cc | 4 ++-- > gcc/cp/semantics.cc | 13 ++++++++++++- > gcc/testsuite/g++.dg/cpp0x/decltype82.C | 10 ++++++++++ > 3 files changed, 24 insertions(+), 3 deletions(-) > create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82.C > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > index e4a473002a0..1ea2545e115 100644 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -6372,7 +6372,7 @@ redeclare_class_template (tree type, tree parms, tree cons) > > /* The actual substitution part of instantiate_non_dependent_expr_sfinae, > to be used when the caller has already checked > - !instantiation_dependent_uneval_expression_p (expr) > + !instantiation_dependent_expression_p (expr) > and cleared processing_template_decl. */ > > tree > @@ -6397,7 +6397,7 @@ instantiate_non_dependent_expr_sfinae (tree expr, tsubst_flags_t complain) > if (processing_template_decl) > { > /* The caller should have checked this already. */ > - gcc_checking_assert (!instantiation_dependent_uneval_expression_p (expr)); > + gcc_checking_assert (!instantiation_dependent_expression_p (expr)); > processing_template_decl_sentinel s; > expr = instantiate_non_dependent_expr_internal (expr, complain); > } > diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc > index 3600d270ff8..b23848ab94c 100644 > --- a/gcc/cp/semantics.cc > +++ b/gcc/cp/semantics.cc > @@ -11302,9 +11302,20 @@ finish_decltype_type (tree expr, bool id_expression_or_member_access_p, > > return type; > } > + else if (processing_template_decl > + && potential_constant_expression (expr) > + && value_dependent_expression_p (expr)) > + /* The above test is equivalent to instantiation_dependent_expression_p > + after instantiation_dependent_uneval_expression_p has been ruled out. > + In this case the expression is dependent but not type-dependent, so > + we can resolve the decltype ahead of time but we can't instantiate > + the expression. */; > else if (processing_template_decl) > { > - expr = instantiate_non_dependent_expr_sfinae (expr, complain|tf_decltype); > + /* The expression isn't instantiation dependent, so we can fully > + instantiate it ahead of time. */ > + expr = instantiate_non_dependent_expr_sfinae (expr, > + complain|tf_decltype); > if (expr == error_mark_node) > return error_mark_node; > /* Keep processing_template_decl cleared for the rest of the function > diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82.C b/gcc/testsuite/g++.dg/cpp0x/decltype82.C > new file mode 100644 > index 00000000000..915e5e37675 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp0x/decltype82.C > @@ -0,0 +1,10 @@ > +// PR c++/105756 > +// { dg-do compile { target c++11 } } > + > +template<int N> > +void f() { > + using ty1 = decltype((5 % N) == 0); > + using ty2 = decltype((5 / N) == 0); > +} > + > +template void f<0>();
On Thu, 2 Jun 2022, Jason Merrill wrote: > On 6/1/22 14:20, Patrick Palka wrote: > > r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent > > decltype operands by relaxing instantiate_non_dependent_expr to check > > instantiation_dependent_uneval_expression_p. But as the testcase below > > demonstrates, this predicate is too permissive here because it allows > > value-dependent-only expressions to go through and get instantiated > > ahead of time, which causes us to crash during constexpr evaluation of > > (5 % N). > > Why are we doing constexpr evaluation in unevaluated context? Looks like because cp_build_binary_op attempts to fold the resulting operator expression via cp_fully_fold (which performs speculate constexpr evaluation): 6261 if (!processing_template_decl) 6262 { 6263 if (resultcode == SPACESHIP_EXPR) 6264 result = get_target_expr (result, complain); 6265 op0 = cp_fully_fold (op0); 6266 /* Only consider the second argument if the first isn't overflowed. */ 6267 if (!CONSTANT_CLASS_P (op0) || TREE_OVERFLOW_P (op0)) 6268 return result; 6269 op1 = cp_fully_fold (op1); 6270 if (!CONSTANT_CLASS_P (op1) || TREE_OVERFLOW_P (op1)) 6271 return result; 6272 } But in an unevaluated context I suppose we don't need or want to do this folding. I'll work on a patch to that effect. > > > This patch strengthens instantiate_non_dependent_expr to use the > > non-uneval version of the predicate instead, which does consider value > > dependence. In turn, we need to make finish_decltype_type avoid calling > > i_n_d_e on a value-dependent-only expression; I assume we still want to > > resolve the decltype ahead of time in this case. (Doing so seems > > unintuitive to me since the expression could be ill-formed at > > instantiation time as in the testcase, but it matches the behavior of > > Clang and MSVC.) > > I don't think there's any problem with the testcase; decltype(1/0) is > well-formed because the expression is not evaluated. D'oh, that makes sense, not sure what I was on about :) > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > > trunk/12? > > > > PR c++/105756 > > > > gcc/cp/ChangeLog: > > > > * pt.cc (instantiate_non_dependent_expr_internal): Adjust > > comment. > > (instantiate_non_dependent_expr_sfinae): Assert i_d_e_p instead > > of i_d_u_e_p. > > * semantics.cc (finish_decltype_type): Don't instantiate the > > expression when i_d_e_p is true. > > > > gcc/testsuite/ChangeLog: > > > > * g++.dg/cpp0x/decltype82.C: New test. > > --- > > gcc/cp/pt.cc | 4 ++-- > > gcc/cp/semantics.cc | 13 ++++++++++++- > > gcc/testsuite/g++.dg/cpp0x/decltype82.C | 10 ++++++++++ > > 3 files changed, 24 insertions(+), 3 deletions(-) > > create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82.C > > > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > > index e4a473002a0..1ea2545e115 100644 > > --- a/gcc/cp/pt.cc > > +++ b/gcc/cp/pt.cc > > @@ -6372,7 +6372,7 @@ redeclare_class_template (tree type, tree parms, tree > > cons) > > /* The actual substitution part of > > instantiate_non_dependent_expr_sfinae, > > to be used when the caller has already checked > > - !instantiation_dependent_uneval_expression_p (expr) > > + !instantiation_dependent_expression_p (expr) > > and cleared processing_template_decl. */ > > tree > > @@ -6397,7 +6397,7 @@ instantiate_non_dependent_expr_sfinae (tree expr, > > tsubst_flags_t complain) > > if (processing_template_decl) > > { > > /* The caller should have checked this already. */ > > - gcc_checking_assert (!instantiation_dependent_uneval_expression_p > > (expr)); > > + gcc_checking_assert (!instantiation_dependent_expression_p (expr)); > > processing_template_decl_sentinel s; > > expr = instantiate_non_dependent_expr_internal (expr, complain); > > } > > diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc > > index 3600d270ff8..b23848ab94c 100644 > > --- a/gcc/cp/semantics.cc > > +++ b/gcc/cp/semantics.cc > > @@ -11302,9 +11302,20 @@ finish_decltype_type (tree expr, bool > > id_expression_or_member_access_p, > > return type; > > } > > + else if (processing_template_decl > > + && potential_constant_expression (expr) > > + && value_dependent_expression_p (expr)) > > + /* The above test is equivalent to instantiation_dependent_expression_p > > + after instantiation_dependent_uneval_expression_p has been ruled > > out. > > + In this case the expression is dependent but not type-dependent, so > > + we can resolve the decltype ahead of time but we can't instantiate > > + the expression. */; > > else if (processing_template_decl) > > { > > - expr = instantiate_non_dependent_expr_sfinae (expr, > > complain|tf_decltype); > > + /* The expression isn't instantiation dependent, so we can fully > > + instantiate it ahead of time. */ > > + expr = instantiate_non_dependent_expr_sfinae (expr, > > + complain|tf_decltype); > > if (expr == error_mark_node) > > return error_mark_node; > > /* Keep processing_template_decl cleared for the rest of the > > function > > diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82.C > > b/gcc/testsuite/g++.dg/cpp0x/decltype82.C > > new file mode 100644 > > index 00000000000..915e5e37675 > > --- /dev/null > > +++ b/gcc/testsuite/g++.dg/cpp0x/decltype82.C > > @@ -0,0 +1,10 @@ > > +// PR c++/105756 > > +// { dg-do compile { target c++11 } } > > + > > +template<int N> > > +void f() { > > + using ty1 = decltype((5 % N) == 0); > > + using ty2 = decltype((5 / N) == 0); > > +} > > + > > +template void f<0>(); > >
On Thu, 2 Jun 2022, Patrick Palka wrote: > On Thu, 2 Jun 2022, Jason Merrill wrote: > > > On 6/1/22 14:20, Patrick Palka wrote: > > > r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent > > > decltype operands by relaxing instantiate_non_dependent_expr to check > > > instantiation_dependent_uneval_expression_p. But as the testcase below > > > demonstrates, this predicate is too permissive here because it allows > > > value-dependent-only expressions to go through and get instantiated > > > ahead of time, which causes us to crash during constexpr evaluation of > > > (5 % N). > > > > Why are we doing constexpr evaluation in unevaluated context? > > Looks like because cp_build_binary_op attempts to fold the resulting > operator expression via cp_fully_fold (which performs speculate > constexpr evaluation): > > 6261 if (!processing_template_decl) > 6262 { > 6263 if (resultcode == SPACESHIP_EXPR) > 6264 result = get_target_expr (result, complain); > 6265 op0 = cp_fully_fold (op0); > 6266 /* Only consider the second argument if the first isn't overflowed. */ > 6267 if (!CONSTANT_CLASS_P (op0) || TREE_OVERFLOW_P (op0)) > 6268 return result; > 6269 op1 = cp_fully_fold (op1); > 6270 if (!CONSTANT_CLASS_P (op1) || TREE_OVERFLOW_P (op1)) > 6271 return result; > 6272 } > > But in an unevaluated context I suppose we don't need or want to do this > folding. I'll work on a patch to that effect. Here it is: -- >8 -- Subject: [PATCH] c++: value-dep but not type-dep decltype operand [PR105756] Here we're crashing when instantiating ahead of time the value-dependent but not type-dependent decltype operand (5 % N) == 0, ultimately because cp_build_binary_op folds its operands for sake of its overflow diagnostics, and as part of this folding it performs speculative constexpr evaluation for the operand (5 % N) during which we crash since it's value-dependent. Since the operand folding performed by cp_build_binary_op appears to be solely for sake of diagnosing overflow, and since these diagnostics are suppressed when in an unevaluated context, this patch fixes this crash by suppressing cp_build_binary_op's operand folding accordingly. Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/12? The diff was generated with -w to suppress noisy whitespace changes. PR c++/105756 gcc/cp/ChangeLog: * typeck.cc (cp_build_binary_op): Don't fold operands when c_inhibit_evaluation_warnings. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/decltype82.C: New test. --- gcc/cp/typeck.cc | 8 ++++++-- gcc/testsuite/g++.dg/cpp0x/decltype82.C | 10 ++++++++++ 2 files changed, 16 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82.C diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc index 190d710cd27..7c910d57b7e 100644 --- a/gcc/cp/typeck.cc +++ b/gcc/cp/typeck.cc @@ -6263,10 +6263,13 @@ cp_build_binary_op (const op_location_t &location, result = build2 (COMPOUND_EXPR, TREE_TYPE (result), instrument_expr, result); + if (resultcode == SPACESHIP_EXPR && !processing_template_decl) + result = get_target_expr_sfinae (result, complain); + + if (!c_inhibit_evaluation_warnings) + { if (!processing_template_decl) { - if (resultcode == SPACESHIP_EXPR) - result = get_target_expr_sfinae (result, complain); op0 = cp_fully_fold (op0); /* Only consider the second argument if the first isn't overflowed. */ if (!CONSTANT_CLASS_P (op0) || TREE_OVERFLOW_P (op0)) @@ -6282,6 +6285,7 @@ cp_build_binary_op (const op_location_t &location, result_ovl = fold_build2 (resultcode, build_type, op0, op1); if (TREE_OVERFLOW_P (result_ovl)) overflow_warning (location, result_ovl); + } return result; } diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82.C b/gcc/testsuite/g++.dg/cpp0x/decltype82.C new file mode 100644 index 00000000000..915e5e37675 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/decltype82.C @@ -0,0 +1,10 @@ +// PR c++/105756 +// { dg-do compile { target c++11 } } + +template<int N> +void f() { + using ty1 = decltype((5 % N) == 0); + using ty2 = decltype((5 / N) == 0); +} + +template void f<0>();
On 6/3/22 14:13, Patrick Palka wrote: > On Thu, 2 Jun 2022, Patrick Palka wrote: > >> On Thu, 2 Jun 2022, Jason Merrill wrote: >> >>> On 6/1/22 14:20, Patrick Palka wrote: >>>> r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent >>>> decltype operands by relaxing instantiate_non_dependent_expr to check >>>> instantiation_dependent_uneval_expression_p. But as the testcase below >>>> demonstrates, this predicate is too permissive here because it allows >>>> value-dependent-only expressions to go through and get instantiated >>>> ahead of time, which causes us to crash during constexpr evaluation of >>>> (5 % N). >>> >>> Why are we doing constexpr evaluation in unevaluated context? >> >> Looks like because cp_build_binary_op attempts to fold the resulting >> operator expression via cp_fully_fold (which performs speculate >> constexpr evaluation): >> >> 6261 if (!processing_template_decl) >> 6262 { >> 6263 if (resultcode == SPACESHIP_EXPR) >> 6264 result = get_target_expr (result, complain); >> 6265 op0 = cp_fully_fold (op0); >> 6266 /* Only consider the second argument if the first isn't overflowed. */ >> 6267 if (!CONSTANT_CLASS_P (op0) || TREE_OVERFLOW_P (op0)) >> 6268 return result; >> 6269 op1 = cp_fully_fold (op1); >> 6270 if (!CONSTANT_CLASS_P (op1) || TREE_OVERFLOW_P (op1)) >> 6271 return result; >> 6272 } >> >> But in an unevaluated context I suppose we don't need or want to do this >> folding. I'll work on a patch to that effect. > > Here it is: > > -- >8 -- > Subject: [PATCH] c++: value-dep but not type-dep decltype operand [PR105756] > > Here we're crashing when instantiating ahead of time the value-dependent > but not type-dependent decltype operand (5 % N) == 0, ultimately > because cp_build_binary_op folds its operands for sake of its overflow > diagnostics, and as part of this folding it performs speculative > constexpr evaluation for the operand (5 % N) during which we crash since > it's value-dependent. > > Since the operand folding performed by cp_build_binary_op appears to > be solely for sake of diagnosing overflow, and since these diagnostics > are suppressed when in an unevaluated context, this patch fixes this > crash by suppressing cp_build_binary_op's operand folding accordingly. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for > trunk/12? The diff was generated with -w to suppress noisy whitespace > changes. OK. > PR c++/105756 > > gcc/cp/ChangeLog: > > * typeck.cc (cp_build_binary_op): Don't fold operands > when c_inhibit_evaluation_warnings. > > gcc/testsuite/ChangeLog: > > * g++.dg/cpp0x/decltype82.C: New test. > --- > gcc/cp/typeck.cc | 8 ++++++-- > gcc/testsuite/g++.dg/cpp0x/decltype82.C | 10 ++++++++++ > 2 files changed, 16 insertions(+), 2 deletions(-) > create mode 100644 gcc/testsuite/g++.dg/cpp0x/decltype82.C > > diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc > index 190d710cd27..7c910d57b7e 100644 > --- a/gcc/cp/typeck.cc > +++ b/gcc/cp/typeck.cc > @@ -6263,10 +6263,13 @@ cp_build_binary_op (const op_location_t &location, > result = build2 (COMPOUND_EXPR, TREE_TYPE (result), > instrument_expr, result); > > + if (resultcode == SPACESHIP_EXPR && !processing_template_decl) > + result = get_target_expr_sfinae (result, complain); > + > + if (!c_inhibit_evaluation_warnings) > + { > if (!processing_template_decl) > { > - if (resultcode == SPACESHIP_EXPR) > - result = get_target_expr_sfinae (result, complain); > op0 = cp_fully_fold (op0); > /* Only consider the second argument if the first isn't overflowed. */ > if (!CONSTANT_CLASS_P (op0) || TREE_OVERFLOW_P (op0)) > @@ -6282,6 +6285,7 @@ cp_build_binary_op (const op_location_t &location, > result_ovl = fold_build2 (resultcode, build_type, op0, op1); > if (TREE_OVERFLOW_P (result_ovl)) > overflow_warning (location, result_ovl); > + } > > return result; > } > diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82.C b/gcc/testsuite/g++.dg/cpp0x/decltype82.C > new file mode 100644 > index 00000000000..915e5e37675 > --- /dev/null > +++ b/gcc/testsuite/g++.dg/cpp0x/decltype82.C > @@ -0,0 +1,10 @@ > +// PR c++/105756 > +// { dg-do compile { target c++11 } } > + > +template<int N> > +void f() { > + using ty1 = decltype((5 % N) == 0); > + using ty2 = decltype((5 / N) == 0); > +} > + > +template void f<0>();
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc index e4a473002a0..1ea2545e115 100644 --- a/gcc/cp/pt.cc +++ b/gcc/cp/pt.cc @@ -6372,7 +6372,7 @@ redeclare_class_template (tree type, tree parms, tree cons) /* The actual substitution part of instantiate_non_dependent_expr_sfinae, to be used when the caller has already checked - !instantiation_dependent_uneval_expression_p (expr) + !instantiation_dependent_expression_p (expr) and cleared processing_template_decl. */ tree @@ -6397,7 +6397,7 @@ instantiate_non_dependent_expr_sfinae (tree expr, tsubst_flags_t complain) if (processing_template_decl) { /* The caller should have checked this already. */ - gcc_checking_assert (!instantiation_dependent_uneval_expression_p (expr)); + gcc_checking_assert (!instantiation_dependent_expression_p (expr)); processing_template_decl_sentinel s; expr = instantiate_non_dependent_expr_internal (expr, complain); } diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc index 3600d270ff8..b23848ab94c 100644 --- a/gcc/cp/semantics.cc +++ b/gcc/cp/semantics.cc @@ -11302,9 +11302,20 @@ finish_decltype_type (tree expr, bool id_expression_or_member_access_p, return type; } + else if (processing_template_decl + && potential_constant_expression (expr) + && value_dependent_expression_p (expr)) + /* The above test is equivalent to instantiation_dependent_expression_p + after instantiation_dependent_uneval_expression_p has been ruled out. + In this case the expression is dependent but not type-dependent, so + we can resolve the decltype ahead of time but we can't instantiate + the expression. */; else if (processing_template_decl) { - expr = instantiate_non_dependent_expr_sfinae (expr, complain|tf_decltype); + /* The expression isn't instantiation dependent, so we can fully + instantiate it ahead of time. */ + expr = instantiate_non_dependent_expr_sfinae (expr, + complain|tf_decltype); if (expr == error_mark_node) return error_mark_node; /* Keep processing_template_decl cleared for the rest of the function diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype82.C b/gcc/testsuite/g++.dg/cpp0x/decltype82.C new file mode 100644 index 00000000000..915e5e37675 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/decltype82.C @@ -0,0 +1,10 @@ +// PR c++/105756 +// { dg-do compile { target c++11 } } + +template<int N> +void f() { + using ty1 = decltype((5 % N) == 0); + using ty2 = decltype((5 / N) == 0); +} + +template void f<0>();