From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 97A9A3858401 for ; Sun, 7 Nov 2021 23:31:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 97A9A3858401 Received: by mail-pj1-x1032.google.com with SMTP id gn3so6812793pjb.0 for ; Sun, 07 Nov 2021 15:31:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4G0Nb39c5beKffklqcH/CnO+QOBGxh1ff0kwhmAQnq4=; b=RcgyZSs2S/4scbcA8Kiqe9tC2psRRgKg32QdZucXS//jthHidC+jnFFr+e3x+UquRd QxsvmQ6dfXE36sJNevPQOO3rnpWU4GtMwWC97Zw7KD7iQ4B0Q1R7QohAX/2jr02E513/ 5vsMJMMnL+UOE82oSCjhy5qUPcytVkMTv9fDAXjPJMg06IdvHNXbLg2Tdxl4lUbopYxt o5ys/pGv8L3/mWCUrRTp13QcmfNJPSaBkBj4dOb+5p44I0Q3CwdLPYsn8HKyPv5Q2jJ8 /kGKwcj8L6eMy9QxZohnirDB5cjOAMf00KsNqPfqEN6tw+pcoy9uL8w63t44CSOj4Zz1 G+7g== X-Gm-Message-State: AOAM530NuYjaDsQEIP/tkjR3/JdaB6WvvqG8GeN6N2q5kdO3jhwn9y6q A8dpPl3IGa8090tiGwebKLxiFBrOgZI= X-Google-Smtp-Source: ABdhPJxSdwsZtmKmR+eunhrb63Jm8c+cqHx8rLWalC3Sw3IWji/NFjE+yavrjwfLiHoX7St0lLhc4w== X-Received: by 2002:a17:90b:1293:: with SMTP id fw19mr47641484pjb.155.1636327891303; Sun, 07 Nov 2021 15:31:31 -0800 (PST) Received: from [192.168.0.41] (184-96-250-76.hlrn.qwest.net. [184.96.250.76]) by smtp.gmail.com with ESMTPSA id k5sm11088287pjd.46.2021.11.07.15.31.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 07 Nov 2021 15:31:31 -0800 (PST) Subject: PING [PATCH] restore ancient -Waddress for weak symbols [PR33925] From: Martin Sebor To: Jason Merrill , "Joseph S. Myers" Cc: gcc-patches References: <679cf10f-e16a-e318-0e82-820efb109d0f@gmail.com> <24cd9565-b127-6534-d98e-7482b3dc082f@gmail.com> Message-ID: <963ef517-3556-cd5c-e756-53df72f0a541@gmail.com> Date: Sun, 7 Nov 2021 16:31:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <24cd9565-b127-6534-d98e-7482b3dc082f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: Sun, 07 Nov 2021 23:31:34 -0000 Ping: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582415.html On 10/23/21 5:06 PM, Martin Sebor wrote: > On 10/4/21 3:37 PM, Jason Merrill wrote: >> On 10/4/21 14:42, Martin Sebor wrote: >>> While resolving the recent -Waddress enhancement request (PR >>> PR102103) I came across a 2007 problem report about GCC 4 having >>> stopped warning for using the address of inline functions in >>> equality comparisons with null.  With inline functions being >>> commonplace in C++ this seems like an important use case for >>> the warning. >>> >>> The change that resulted in suppressing the warning in these >>> cases was introduced inadvertently in a fix for PR 22252. >>> >>> To restore the warning, the attached patch enhances >>> the decl_with_nonnull_addr_p() function to return true also for >>> weak symbols for which a definition has been provided. >> >> I think you probably want to merge this function with >> fold-const.c:maybe_nonzero_address, which already handles more cases. > > maybe_nonzero_address() doesn't behave quite like > decl_with_nonnull_addr_p() expects and I'm reluctant to muck > around with the former too much since it's used for codegen, > while the latter just for warnings.  (There is even a case > where the functions don't behave the same, and would result > in different warnings between C and C++ without some extra > help.) > > So in the attached revision I just have maybe_nonzero_address() > call decl_with_nonnull_addr_p() and then refine the failing > (or uncertain) cases separately, with some overlap between > them. > > Since I worked on this someone complained that some instances > of the warning newly enhanced under PR102103 aren't suppresed > in code resulting from macro expansion.  Since it's trivial, > I include the fix for that report in this patch as well. > > Tested on x86_64-linux. > > Martin