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 669693857025 for ; Thu, 8 Jul 2021 20:26:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 669693857025 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-389-0u6rLaVhOUuNlhMar_3zpQ-1; Thu, 08 Jul 2021 16:26:09 -0400 X-MC-Unique: 0u6rLaVhOUuNlhMar_3zpQ-1 Received: by mail-qv1-f71.google.com with SMTP id h7-20020a0ceda70000b02902af042354f1so4824159qvr.9 for ; Thu, 08 Jul 2021 13:26:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8Cn11KD5faBlwLTlbJxv9b0pFeOfiYCtfyQLgm1Da5k=; b=bvABEPxhdU75Gbq2zHmWZqX+CVu70fgLzCKtgGtb6BfAXbfL9NQ8CXJJngY/MSfc9T 8/eCiO+AGkPP/1pQrnvWXU39RlqM/oLUKsDEZ2t4qYBO24kvUD06BaltZcV5oizl2ql8 qdcdbxVyAoakgcVTVmuxh9Rcfzgg+9AvtEn2naVxa/Y5md6N6a9xd9JzWU5tBS0EwmEg kpnqeZamE488j3TMlDq0kh1TsZpMGuBhXmhn1sO0162QbdVe0xT4ZDhJizxbaQK1/oUy jOTgQmxB+oEwceXx3DvpQIevlBJsnFIRHolsDDkrcAksGRWKP+Yld86ETdPXQQtyihh6 TuXQ== X-Gm-Message-State: AOAM533VFr9SxgysiN830Cn5xRJnQ2bsI2eQiLxmk/SsqRqtU4boaA72 dHvw+byKQ1UBFZ994iRqOKfeYGefPZBC8ICMn4tVNWRrmlT9IPVzn3PL748fljwNkA6rZfXp4W1 BP04VumJ4NwtGQ4TPSQ== X-Received: by 2002:a37:8183:: with SMTP id c125mr32231552qkd.134.1625775968546; Thu, 08 Jul 2021 13:26:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9wuo27gKs2JBKpGRTSZfybCBKE42kxfsc1HaR1oFf1fxuMeAyyeHDL7XDBK6eeQUVLp3TZg== X-Received: by 2002:a37:8183:: with SMTP id c125mr32231542qkd.134.1625775968355; Thu, 08 Jul 2021 13:26:08 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::8e66]) by smtp.gmail.com with ESMTPSA id b25sm1503681qkk.111.2021.07.08.13.26.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Jul 2021 13:26:07 -0700 (PDT) Date: Thu, 8 Jul 2021 16:26:06 -0400 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: Re: [PATCH v2] c++: Fix noexcept with unevaluated operand [PR101087] Message-ID: References: <20210708014058.854624-1-polacek@redhat.com> <1ca95175-4fe6-60d6-d6f1-e634ffdd271c@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) 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=-13.0 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_H4, RCVD_IN_MSPIKE_WL, 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: Thu, 08 Jul 2021 20:26:12 -0000 On Thu, Jul 08, 2021 at 09:35:02AM -0400, Marek Polacek wrote: > On Thu, Jul 08, 2021 at 09:30:27AM -0400, Jason Merrill wrote: > > On 7/7/21 9:40 PM, Marek Polacek wrote: > > > It sounds plausible that this assert > > > > > > int f(); > > > static_assert(noexcept(sizeof(f()))); > > > > > > should pass: sizeof produces a std::size_t and its operand is not > > > evaluated, so it can't throw. noexcept should only evaluate to > > > false for potentially evaluated operands. Therefore I think that > > > check_noexcept_r shouldn't walk into operands of sizeof/decltype/ > > > alignof/typeof. Only checking cp_unevaluated_operand therein does > > > not work, because expr_noexcept_p can be called in an unevaluated > > > context, so I resorted to the following cp_evaluated hack. Does > > > that seem acceptable? > > > > I suppose, but why not check for SIZEOF_EXPR/ALIGNOF_EXPR/NOEXCEPT_EXPR > > directly? > > I thought I would, but then it occurred to me that it might be better to > rely on cp_walk_subtrees which ++/--s cp_unevaluated_operand for those > codes. I'd be happy to change the patch to check those codes directly; > maybe I'm overthinking things here. So here's v2 which checks the codes directly, via a new inline: Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- It sounds plausible that this assert int f(); static_assert(noexcept(sizeof(f()))); should pass: sizeof produces a std::size_t and its operand is not evaluated, so it can't throw. noexcept should only evaluate to false for potentially evaluated operands. Therefore I think that check_noexcept_r shouldn't walk into operands of sizeof/decltype/ alignof/typeof. PR c++/101087 gcc/cp/ChangeLog: * cp-tree.h (unevaluated_p): New. * except.c (check_noexcept_r): Use it. Don't walk into unevaluated operands. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept70.C: New test. --- gcc/cp/cp-tree.h | 13 +++++++++++++ gcc/cp/except.c | 9 ++++++--- gcc/testsuite/g++.dg/cpp0x/noexcept70.C | 5 +++++ 3 files changed, 24 insertions(+), 3 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept70.C diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h index b4501576b26..d4810c0c986 100644 --- a/gcc/cp/cp-tree.h +++ b/gcc/cp/cp-tree.h @@ -8465,6 +8465,19 @@ is_constrained_auto (const_tree t) return is_auto (t) && PLACEHOLDER_TYPE_CONSTRAINTS_INFO (t); } +/* True if CODE, a tree code, denotes a tree whose operand is not evaluated + as per [expr.context], i.e., an operand to sizeof, typeof, decltype, or + alignof. */ + +inline bool +unevaluated_p (tree_code code) +{ + return (code == DECLTYPE_TYPE + || code == ALIGNOF_EXPR + || code == SIZEOF_EXPR + || code == NOEXCEPT_EXPR); +} + /* RAII class to push/pop the access scope for T. */ struct push_access_scope_guard diff --git a/gcc/cp/except.c b/gcc/cp/except.c index a8cea53cf91..a8acbc4b7b2 100644 --- a/gcc/cp/except.c +++ b/gcc/cp/except.c @@ -1033,12 +1033,15 @@ check_handlers (tree handlers) expression whose type is a polymorphic class type (10.3). */ static tree -check_noexcept_r (tree *tp, int * /*walk_subtrees*/, void * /*data*/) +check_noexcept_r (tree *tp, int *walk_subtrees, void *) { tree t = *tp; enum tree_code code = TREE_CODE (t); - if ((code == CALL_EXPR && CALL_EXPR_FN (t)) - || code == AGGR_INIT_EXPR) + + if (unevaluated_p (code)) + *walk_subtrees = false; + else if ((code == CALL_EXPR && CALL_EXPR_FN (t)) + || code == AGGR_INIT_EXPR) { /* We can only use the exception specification of the called function for determining the value of a noexcept expression; we can't use diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept70.C b/gcc/testsuite/g++.dg/cpp0x/noexcept70.C new file mode 100644 index 00000000000..45a6137dd6f --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/noexcept70.C @@ -0,0 +1,5 @@ +// PR c++/101087 +// { dg-do compile { target c++11 } } + +int f(); +static_assert(noexcept(sizeof(f())), ""); base-commit: 763121ccd908f52bc666f277ea2cf42110b3aad9 -- 2.31.1