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 27E9C38618A5 for ; Thu, 2 Jun 2022 20:11:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 27E9C38618A5 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-533-_XKFkwR9PqK5iNFlUKPkdA-1; Thu, 02 Jun 2022 16:10:58 -0400 X-MC-Unique: _XKFkwR9PqK5iNFlUKPkdA-1 Received: by mail-qv1-f72.google.com with SMTP id z10-20020ad4414a000000b004644d6dafe3so4083806qvp.11 for ; Thu, 02 Jun 2022 13:10:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=lT2nFKreJ65jMgZyDSwTJms020B+X6iSEhfqAbbvjzA=; b=sPYI5hCTlZdsLIy0FJaHN45okfqTWI+WVCGWDbS2Ha0cebSDC9NaJ5e78SkMCDRZXA ir1ZDYk4jz1/BXN/kJ+4USBCAPfMQtO/qx1i6s+X3feI8/YMmKRe7qiUi68hWmhs/P2M AvXyYZAnLaFrHcALdmS8ZjDz7XSH+vDCs/CmCxSZJh8sRglEvHtwgPFsdgIGhA6UBBzm XHq+YN4E7XkIxDCwVPXKZ34t9bFSOmKXoRHehF61AbBNzG89PeOZZpd1FOer+CZk40Oy fKZBbApOvG95fvx72ERteLfMt35zcSn4xe1dpOkcbcKVFhNRfQVaErC511h2QLqfm7XF ynrw== X-Gm-Message-State: AOAM530InpexTD5brWRi130qzzjKNyfyerDmvx//ocXhz/TwPnIlWH2I xLxOzXDCEQxImkAIhNaPCJBkuFjwhMZIJLmctgkv9ZloJCZY9QDfB0NtpXaK5oCHu84UOHaGYrx 3FzlkLjJwGKnMCHCZng== X-Received: by 2002:a05:622a:1824:b0:2f3:c196:10d with SMTP id t36-20020a05622a182400b002f3c196010dmr5085309qtc.74.1654200657627; Thu, 02 Jun 2022 13:10:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwx0z/r84u51bgSITVXlOhzr6K4gyw8FkaZkTuFD81hKP+S1hKox+N/sGuOxMeGqpm6ZzyGTA== X-Received: by 2002:a05:622a:1824:b0:2f3:c196:10d with SMTP id t36-20020a05622a182400b002f3c196010dmr5085300qtc.74.1654200657399; Thu, 02 Jun 2022 13:10:57 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::9979]) by smtp.gmail.com with ESMTPSA id bv17-20020a05622a0a1100b00303b4c16991sm3172006qtb.47.2022.06.02.13.10.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Jun 2022 13:10:56 -0700 (PDT) Date: Thu, 2 Jun 2022 16:10:54 -0400 From: Marek Polacek To: Jason Merrill Cc: Patrick Palka , GCC Patches Subject: Re: [PATCH] c++: ICE with template NEW_EXPR [PR105803] Message-ID: References: <20220601224536.1553412-1-polacek@redhat.com> <68b3a5ff-698d-e680-6c94-b9aa5b7f3127@redhat.com> MIME-Version: 1.0 In-Reply-To: <68b3a5ff-698d-e680-6c94-b9aa5b7f3127@redhat.com> User-Agent: Mutt/2.2.1 (2022-02-19) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-12.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_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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2022 20:11:01 -0000 On Thu, Jun 02, 2022 at 03:42:15PM -0400, Jason Merrill wrote: > On 6/2/22 10:03, Marek Polacek wrote: > > On Thu, Jun 02, 2022 at 08:42:36AM -0400, Patrick Palka wrote: > > > On Wed, 1 Jun 2022, Marek Polacek via Gcc-patches wrote: > > > > > > > Here we ICE because value_dependent_expression_p gets a NEW_EXPR > > > > whose operand is a type, and we go to the default case which just > > > > calls v_d_e_p on each operand of the NEW_EXPR. Since one of them > > > > is a type, we crash on the new assert in t_d_e_p. > > > > > > Looks like NEW_EXPR is considered to be not potentially constant > > > according to potential_constant_expression. I thought we shouldn't > > > be calling value_dependent_expression_p on such exprs? > > Except in C++20 new-expressions are potentially constant, so the patch is Thanks, pushed. > OK, and we should adjust pce1 accordingly. Is the attached patch OK then? So far dg.exp passed. Though it won't help with... > I notice we currently fail to handle > > struct A > { > int i; > constexpr A(int *p): i(*p) { delete p; } > }; > > constexpr int i = A(new int(42)).i; > > though it does work inside a function. ...this test (it complains about a TARGET_EXPR's slot variable not being declared constexpr), so I'm going to open a PR. >From cf70354894bc31cc542ed8df40633bea2427fee7 Mon Sep 17 00:00:00 2001 From: Marek Polacek Date: Thu, 2 Jun 2022 15:56:18 -0400 Subject: [PATCH] c++: new-expression is potentially constant in C++20 ... so adjust p_c_e accordingly. gcc/cp/ChangeLog: * constexpr.cc (potential_constant_expression_1): Treat {,VEC_}NEW_EXPR as potentially constant in C++20. --- gcc/cp/constexpr.cc | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc index 1346a1d4c10..2bbd8785627 100644 --- a/gcc/cp/constexpr.cc +++ b/gcc/cp/constexpr.cc @@ -9039,10 +9039,18 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict, bool now, "before C++17"); return false; - case DYNAMIC_CAST_EXPR: - case PSEUDO_DTOR_EXPR: case NEW_EXPR: case VEC_NEW_EXPR: + if (cxx_dialect >= cxx20) + /* In C++20, new-expressions are potentially constant. */ + return true; + else if (flags & tf_error) + error_at (loc, "new-expression is not a constant expression " + "before C++20"); + return false; + + case DYNAMIC_CAST_EXPR: + case PSEUDO_DTOR_EXPR: case DELETE_EXPR: case VEC_DELETE_EXPR: case THROW_EXPR: base-commit: 7b98910406b5000a6429c188b0c6cc14e3140637 -- 2.36.1