From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rock.gnat.com (rock.gnat.com [IPv6:2620:20:4000:0:a9e:1ff:fe9b:1d1]) by sourceware.org (Postfix) with ESMTPS id 67AEF3858D33 for ; Wed, 22 Feb 2023 16:04:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 67AEF3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 159F6116102; Wed, 22 Feb 2023 11:04:07 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cn+JqJE3m5Zn; Wed, 22 Feb 2023 11:04:07 -0500 (EST) Received: from free.home (tron.gnat.com [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id 472961160FC; Wed, 22 Feb 2023 11:04:06 -0500 (EST) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTPS id 31MG3ipV293720 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 22 Feb 2023 13:03:45 -0300 From: Alexandre Oliva To: Jason Merrill Cc: gcc-patches@gcc.gnu.org, nathan@acm.org, nickc@redhat.com, richard.earnshaw@arm.com, ramana.gcc@gmail.com, kyrylo.tkachov@arm.com, ro@CeBiTec.Uni-Bielefeld.DE, mikestump@comcast.net Subject: Re: [PATCH] Accept pmf-vbit-in-delta extra warning Organization: Free thinker, does not speak for AdaCore References: Errors-To: aoliva@lxoliva.fsfla.org Date: Wed, 22 Feb 2023 13:03:44 -0300 In-Reply-To: (Jason Merrill's message of "Fri, 17 Feb 2023 12:11:03 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,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 Feb 17, 2023, Jason Merrill wrote: > On 2/17/23 23:02, Alexandre Oliva wrote: >> >> cp_build_binary_op, that issues -Waddress warnings, issues an extra >> warning on arm targets, that g++.dg/warn/Waddress-5.C does not expect >> when comparing a pointer-to-member-function literal with null. >> >> The reason for the extra warning is that, on arm targets, >> TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, which >> causes a different path to be taken, that extracts the >> pointer-to-function and the delta fields (minus the vbit) and compares >> each one with zero. It's when comparing this pointer-to-function with >> zero, in a recursive cp_build_binary_op, that another warning is >> issued. >> >> I suppose there should be a way to skip the warning in this recursive >> call, without disabling other warnings that might be issued there, but > warning_sentinel ws (warn_address) Oh, yeah, that will suppress the expected warning for pfn0, but isn't there any risk whatsoever that it could suppress other -Waddress warnings for tree operands of pfn0? I see the cp_save_expr for side effects, but what if e.g. the pmfn we're testing is an array element, and the index expression tests another pmfn against NULL that should be warned about? Or something else that wouldn't have TREE_SIDE_EFFECTS, and would thus not go through cp_save_expr. Would we then warn for uses of both pfn0 and delta0? Here's what I'm going to test for these concerns. Ok to install if it bootstraps successfully, and my concerns are unfounded? [c++] suppress redundant null-addr warn in pfn from pmfn From: Alexandre Oliva When TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta, when we warn about comparing a pointer-to-member-function with NULL, we also warn about comparing the pointer-to-function extracted from it with NULL, which is redundant. Suppress the redundant warning. for gcc/cp/ChangeLog * typeck.cc (cp_build_binary_op): Suppress redundant warning for pfn null test in pmfn test with vbit-in-delta. --- gcc/cp/typeck.cc | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc index 4afb5e4f0d420..d5a3e501d8e91 100644 --- a/gcc/cp/typeck.cc +++ b/gcc/cp/typeck.cc @@ -5780,11 +5780,18 @@ cp_build_binary_op (const op_location_t &location, pfn0 = pfn_from_ptrmemfunc (op0); delta0 = delta_from_ptrmemfunc (op0); - e1 = cp_build_binary_op (location, - EQ_EXPR, - pfn0, - build_zero_cst (TREE_TYPE (pfn0)), - complain); + { + /* If we will warn below about a null-address compare + involving the orig_op0 ptrmemfunc, we'd likely also + warn about the pfn0's null-address compare, and + that would be redundant, so suppress it. */ + warning_sentinel ws (warn_address); + e1 = cp_build_binary_op (location, + EQ_EXPR, + pfn0, + build_zero_cst (TREE_TYPE (pfn0)), + complain); + } e2 = cp_build_binary_op (location, BIT_AND_EXPR, delta0, -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about