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.133.124]) by sourceware.org (Postfix) with ESMTPS id 971F03858C27 for ; Tue, 26 Sep 2023 23:18:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 971F03858C27 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695770313; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HoBzPOAfrl2LF/UBhDa2f/XrmmhY1CIJOhgQip0/6hI=; b=In6BCjwm5rs21jGm3yJmI8oVBlau04XKmTqgvTjgRCq0TXj5J+sINpAzl9ys11tYH2lMHH cMxZJWfBV+fpQgizD5AX6VF/0nk6JLad8pNUpE4YumfLuRqcVT7BkEFa/K70R33QRwQL6U ty/lA6VItFlGsFoNts3F1hWB5nKX1bw= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-394-Q24lfBRxN2Ce7m4p2jj2sg-1; Tue, 26 Sep 2023 19:18:22 -0400 X-MC-Unique: Q24lfBRxN2Ce7m4p2jj2sg-1 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-4180bc4227bso74875111cf.1 for ; Tue, 26 Sep 2023 16:18:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695770302; x=1696375102; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HoBzPOAfrl2LF/UBhDa2f/XrmmhY1CIJOhgQip0/6hI=; b=lWrJS+XFg7mDWRwlxCB4iujdtvh1LtoaVMD2xk38PYm2kgozM5pgbVxDq7D7VSH4Gc qb+KkOFg0S5rM1rtVJPAm8wr+NZ7Fys0sW2PEVgnaZxNJKKXSigd9uSbTQApltlU/eM3 zY1+M9xAH9/Q2xyQxC1n30C/Yo51bc5K3AXXkKW9eCRR/32l1mVJXNu1eHAo319UhvoU pd77jGFeEpXfk1as3qqYKdO331WgLYcs3+pKXGARg00+1UT3LIgAth7FrOYMESkDcSsK HSSzxD0yTvcshTLihr33uHW34SCh3ILQIxUeF3TIXOAogsaDbwV9ofaFu7p+1MNF7NGu H0Bg== X-Gm-Message-State: AOJu0Yw0o65YmR/CPL7GoEyIhbMtejNjcJ+YpJ3GQIcu4q6xGU8Dz/+l S3iBx7ulR20HPUWcCX3Pz7Wym6ciq8AJjD0RqcMxA5XrcFS3SmM8GaYhfYsO6WUgJP0NDj01APL I7KtdWpEzv+K36Zj9vLJsMZf2gw== X-Received: by 2002:ad4:5942:0:b0:658:310d:2214 with SMTP id eo2-20020ad45942000000b00658310d2214mr3532753qvb.9.1695770302240; Tue, 26 Sep 2023 16:18:22 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH11+Dsd/Rjil0/F683i3TQXA4VzxEyipaVy2gWJNQlPMm9znubIRmIjQkqzWIQ7r561eZMNw== X-Received: by 2002:ad4:5942:0:b0:658:310d:2214 with SMTP id eo2-20020ad45942000000b00658310d2214mr3532739qvb.9.1695770301881; Tue, 26 Sep 2023 16:18:21 -0700 (PDT) Received: from [192.168.1.108] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id r6-20020a0ccc06000000b006584984f3dfsm2399502qvk.26.2023.09.26.16.18.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Sep 2023 16:18:21 -0700 (PDT) Message-ID: <9c6dc81a-8b1f-a0e1-f7f3-8ab77374bd2a@redhat.com> Date: Tue, 26 Sep 2023 19:18:19 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH 1/2] c++: remove NON_DEPENDENT_EXPR, part 1 To: Patrick Palka , gcc-patches@gcc.gnu.org References: <20230925204302.1277285-1-ppalka@redhat.com> From: Jason Merrill In-Reply-To: <20230925204302.1277285-1-ppalka@redhat.com> 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=-12.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 9/25/23 16:43, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK > for trunk? > > -- >8 -- > > This tree code dates all the way back to r69130[1] which implemented > typing of non-dependent expressions. Its motivation was never clear (to > me at least) since the documentation for it in e.g. cp-tree.def doesn't > seem accurate anymore. build_non_dependent_expr has since gained > a bunch of edge cases about whether (or how) to wrap certain templated > trees, making it hard to reason about in general. > > So this patch removes this tree code, and temporarily turns > build_non_dependent_expr into the identity function. The subsequent > patch will remove build_non_dependent_expr and adjust its callers > appropriately. > > We now need to gracefully handle templated (sub)trees in a couple of > places, places which previously didn't see templated trees since they > didn't look through NON_DEPENDENT_EXPR. > > [1]: https://gcc.gnu.org/pipermail/gcc-patches/2003-July/109355.html > > gcc/c-family/ChangeLog: > > * c-warn.cc (check_address_or_pointer_of_packed_member): Handle > templated CALL_EXPR naming a local extern function. > > gcc/cp/ChangeLog: > > * class.cc (instantiate_type): Remove NON_DEPENDENT_EXPR > handling. > * constexpr.cc (cxx_eval_constant_expression): Likewise. > (potential_constant_expression_1): Likewise. > * coroutines.cc (coro_validate_builtin_call): Don't > expect ALIGNOF_EXPR to be wrapped in NON_DEPENDENT_EXPR. > * cp-objcp-common.cc (cp_common_init_ts): Remove > NON_DEPENDENT_EXPR handling. > * cp-tree.def (NON_DEPENDENT_EXPR): Remove. > * cp-tree.h (build_non_dependent_expr): Temporarily redefine as > the identity function. > * cvt.cc (maybe_warn_nodiscard): Handle templated CALL_EXPR > naming a local extern function. > * cxx-pretty-print.cc (cxx_pretty_printer::expression): Remove > NON_DEPENDENT_EXPR handling. > * error.cc (dump_decl): Likewise. > (dump_expr): Likewise. > * expr.cc (mark_use): Likewise. > (mark_exp_read): Likewise. > * pt.cc (build_non_dependent_expr): Remove. > * tree.cc (lvalue_kind): Remove NON_DEPENDENT_EXPR handling. > (cp_stabilize_reference): Likewise. > * typeck.cc (warn_for_null_address): Likewise. > (cp_build_binary_op): Handle type-dependent SIZEOF_EXPR operands. > (cp_build_unary_op) : Don't fold inside a > template. > > gcc/testsuite/ChangeLog: > > * g++.dg/concepts/var-concept3.C: Adjust expected diagnostic > for attempting to call a variable concept. > --- > gcc/c-family/c-warn.cc | 2 +- > gcc/cp/class.cc | 9 -- > gcc/cp/constexpr.cc | 9 -- > gcc/cp/coroutines.cc | 3 +- > gcc/cp/cp-objcp-common.cc | 1 - > gcc/cp/cp-tree.def | 11 --- > gcc/cp/cp-tree.h | 2 +- > gcc/cp/cvt.cc | 4 +- > gcc/cp/cxx-pretty-print.cc | 1 - > gcc/cp/error.cc | 8 -- > gcc/cp/expr.cc | 2 - > gcc/cp/pt.cc | 92 -------------------- > gcc/cp/tree.cc | 5 -- > gcc/cp/typeck.cc | 13 +-- > gcc/testsuite/g++.dg/concepts/var-concept3.C | 2 +- > 15 files changed, 15 insertions(+), 149 deletions(-) > > diff --git a/gcc/c-family/c-warn.cc b/gcc/c-family/c-warn.cc > index e67dd87a773..c07770394bf 100644 > --- a/gcc/c-family/c-warn.cc > +++ b/gcc/c-family/c-warn.cc > @@ -3029,7 +3029,7 @@ check_address_or_pointer_of_packed_member (tree type, tree rhs) > if (TREE_CODE (rhs) == CALL_EXPR) > { > rhs = CALL_EXPR_FN (rhs); /* Pointer expression. */ > - if (rhs == NULL_TREE) > + if (rhs == NULL_TREE || TREE_CODE (rhs) == IDENTIFIER_NODE) > return NULL_TREE; > rhs = TREE_TYPE (rhs); /* Pointer type. */ > /* We could be called while processing a template and RHS could be > a functor. In that case it's a class, not a pointer. */ > if (!POINTER_TYPE_P (rhs)) How about adding !rhs to this condition instead of checking specifically for IDENTIFIER_NODE above? > return NULL_TREE; > @@ -1048,7 +1048,7 @@ maybe_warn_nodiscard (tree expr, impl_conv_void implicit) > call = TARGET_EXPR_INITIAL (expr); > location_t loc = cp_expr_loc_or_input_loc (call); > tree callee = cp_get_callee (call); > - if (!callee) > + if (!callee || identifier_p (callee)) > return; And similarly handling null type here? > @@ -5405,7 +5402,9 @@ cp_build_binary_op (const op_location_t &location, > type0 = TREE_TYPE (type0); > if (!TYPE_P (type1)) > type1 = TREE_TYPE (type1); > - if (INDIRECT_TYPE_P (type0) && same_type_p (TREE_TYPE (type0), type1)) > + if (type0 > + && INDIRECT_TYPE_P (type0) > + && same_type_p (TREE_TYPE (type0), type1)) If type0 were null here, wouldn't we have crashed when checking TYPE_P (type0) a few lines above? Jason