From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 56B253858402 for ; Mon, 4 Oct 2021 22:40:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56B253858402 Received: by mail-wm1-x335.google.com with SMTP id l18-20020a05600c4f1200b002f8cf606262so844942wmq.1 for ; Mon, 04 Oct 2021 15:40:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j+KLqZWAI4PXI5blEJgPhVDxTs/idnKsNx4j7pfwCqE=; b=H4zjpOk9seMS+t+UGiYxnLPqthsZV3fhetaDErc3zB5Kv/uhsXBACQihptKIOj8CIN uyJ4iWuof6Xf5ySxkkHPMZzWJPxgalcEMBfulTNp9orlFQSsoXzuYJHxAzGCGMFcogF5 6C0m0VhF3/r5YD9qXqu4jvhMfKIvkGx03A1VhR5vJPfQEGLBhs0IvXd8ywLqIi1YTvTS a8xB58h9kbW8k2WBpYvpJokcKlbUGFji3+UVSAE32PX/DfWD1IsTThOYWcRc+EEb7mz5 4umGh9p3i8tofVUHc6BXUlEtI48gFgJmMlJ2NDys8sYnZKOtereltWN7niVx5f+4k0zw T8Gg== X-Gm-Message-State: AOAM531ggSc/f8pkpRWlMwu/FvS+60XwdnaarGq/z9iHA0QU8Lt7+JEC cd7+gzFiGR8eo6MOQ9Z1ZNcmZZtHXvfJQFkkMU+zPQ== X-Google-Smtp-Source: ABdhPJwGvwJHHoOSUD8V498tuC/3Cbs1eTfw3RJDAV8x4KlIpxatGfsMmrUsBFEA5Xus2pEllmqs6KfPRjWtdxf3syc= X-Received: by 2002:a1c:2395:: with SMTP id j143mr16891676wmj.107.1633387203390; Mon, 04 Oct 2021 15:40:03 -0700 (PDT) MIME-Version: 1.0 References: <679cf10f-e16a-e318-0e82-820efb109d0f@gmail.com> In-Reply-To: <679cf10f-e16a-e318-0e82-820efb109d0f@gmail.com> From: Eric Gallager Date: Mon, 4 Oct 2021 18:39:52 -0400 Message-ID: Subject: Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925] To: Martin Sebor Cc: "Joseph S. Myers" , Jason Merrill , gcc-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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: Mon, 04 Oct 2021 22:40:05 -0000 On Mon, Oct 4, 2021 at 2:43 PM Martin Sebor via Gcc-patches 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. > > Tested on x86_64-linux and by comparing the GCC output for new > test cases to Clang's which diagnoses all but one instance of > these cases with either -Wtautological-pointer-compare or > -Wpointer-bool-conversion, depending on context. Would it make sense to use the same names as clang's flags here, too, instead of dumping them all under -Waddress? I think the additional granularity could be helpful for people who only want some warnings, but not others. > The one case where Clang doesn't issue a warning but GCC > with the patch does is for a symbol explicitly declared with > attribute weak for which a definition has been provided. > I believe the address of such symbols is necessarily nonnull and > so issuing the warning is helpful > (both GCC and Clang fold such comparisons to a constant). > > Martin