From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 6DF263858415 for ; Wed, 9 Mar 2022 13:18:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6DF263858415 Received: by mail-ej1-x631.google.com with SMTP id p15so4920907ejc.7 for ; Wed, 09 Mar 2022 05:18:09 -0800 (PST) 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=HLK1ZSegHR4ISCcq7QK0AqjkjG+XEOjwMSm7tDiPStE=; b=B2z2Mm5g/pKujJacErqMyuolqwj0k3HGGYdZkGk8SJ5j6fmowEYBnxM8wnhh34qVqB NhG4X5OoqJvRcYcWhBBFp5IO2cZiPCe+tbb3LLSgs2cfe22GJIBrA+46Q/JAghdaETY/ WoWBSpQzNzfBOdEdyLbgo6cgm0bZyNJS2CNLmUvEPnBfA1rupwJMBAYjyja2crM6sJzT X3NL4qmjrYG4vGqImK/tLjLr7XwXx9fsIEzGiRswbz6cDg7E9DkmrzDirsJtvAfSlv7U /Ebkg4ydF4+A7ZXDblSkyPDXW7v0hccB/a8u/EypRUzpDn/wdEgNIyuw9VFvLJHn7s5P k/AQ== X-Gm-Message-State: AOAM533C1W2LBmKEu4gqd1gpxZ3wnKR78S8G04LS/kuM7A9I73rz/228 jOJH2IgK1T/w3wnl/UUYHadsy1uEu4zbiHZQv64= X-Google-Smtp-Source: ABdhPJzWpd9myKX0WAO1tZBQJVe8tcFN9CnLeGXcheXS6GD7OoNWx3yecgLxbtg0CzAuLQb2dxyKXbRQdLnZB9D5cOo= X-Received: by 2002:a17:906:b893:b0:6da:ab5e:ea34 with SMTP id hb19-20020a170906b89300b006daab5eea34mr17691869ejb.657.1646831888258; Wed, 09 Mar 2022 05:18:08 -0800 (PST) MIME-Version: 1.0 References: <93612754-9bd2-7e45-f6fa-1704c2f78c54@gmail.com> <74c7ee44-1817-187c-9e0d-b9b8e052fa1b@redhat.com> In-Reply-To: From: Richard Biener Date: Wed, 9 Mar 2022 14:17:57 +0100 Message-ID: Subject: Re: [PATCH] handle "invisible" reference in -Wdangling-pointer (PR104436) To: Martin Sebor Cc: Jason Merrill , gcc-patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.6 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, T_SCC_BODY_TEXT_LINE 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: Wed, 09 Mar 2022 13:18:11 -0000 On Fri, Feb 11, 2022 at 12:05 AM Martin Sebor via Gcc-patches wrote: > > On 2/8/22 15:37, Jason Merrill wrote: > > On 2/8/22 16:59, Martin Sebor wrote: > >> Transforming a by-value arguments to by-reference as GCC does for some > >> class types can trigger -Wdangling-pointer when the argument is used > >> to store the address of a local variable. Since the stored value is > >> not accessible in the caller the warning is a false positive. > >> > >> The attached patch handles this case by excluding PARM_DECLs with > >> the DECL_BY_REFERENCE bit set from consideration. > >> > >> While testing the patch I noticed some instances of the warning are > >> uninitentionally duplicated as the pass runs more than once. To avoid > >> that, I also introduce warning suppression into the handler for this > >> instance of the warning. (There might still be others.) > > > > The second test should verify that we do warn about returning 't' from a > > function; we don't want to ignore the DECL_BY_REFERENCE RESULT_DECL. > > The indirect aggregate case isn't handled and needs more work but > since you brought it up I thought I should look into finishing it. > The attached patch #2 adds support for it. It also incorporates > Richard's suggestion to test PARM_DECL. Patch #2 applies on top > of patch #1 which is unchanged from the first revision. patch #1 would be OK if you'd do the PARM_DECL check there - I'd rather defer #2 to stage1. Richard. > > I have retested it on x86_64-linux and by building Glibc and > Binutils + GDB. > > If now is too late for the aggregate enhancement I'm okay with > deferring it until stage 1. > > > > >> + tree var = SSA_NAME_VAR (lhs_ref.ref); > >> + if (DECL_BY_REFERENCE (var)) > >> + /* Avoid by-value arguments transformed into by-reference. */ > >> + continue; > > > > I wonder if we can we express this property of invisiref parms somewhere > > more general? I imagine optimizations would find it useful as well. > > Could pointer_query somehow treat the reference as pointing to a > > function-local object? > > I don't quite see where in the pointer_query class this would be > useful (the class also isn't used for optimization). I could add > a helper to the access_ref class to query this property in warning > code but as this is the only potential client I'm also not sure > that's quite what you had in mind. I'd need some guidance as to > what you're thinking of here. > > Martin > > > > > > I previously tried to express this by marking the reference as > > 'restrict', but that was wrong > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474). > > > > Jason > >