gimple-ssa-warn-access: Fix up asan_test.C -Wdangling-pointer regression [PR104103]
Message ID | 20220118235610.GN2646553@tucnak |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 73DCF3857C4D for <patchwork@sourceware.org>; Tue, 18 Jan 2022 23:56:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 73DCF3857C4D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1642550207; bh=+Xz6z3iTnXVWSrqOfqigxs8/sxWiMeygL3BBk4HKA7E=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=E+tMu2BOt7aOmQBKt5nGSK3wWxKbejD/cStbUZbLlDoqHFnUXq3Y9ixS5tn55cmj1 ZIbUGiNrL3FWw87rusCp8U/l1D7X0cEpJO9DZKoPiO8FDCMw5xyCqR+lqiEPq/l90f ag+OXQZgqIQ+atl0tX2pRs9jRG9HgC7A7wa8vfjc= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 9244B3858409 for <gcc-patches@gcc.gnu.org>; Tue, 18 Jan 2022 23:56:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9244B3858409 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-660-dPxA6w8bMouL0lyByTZMCw-1; Tue, 18 Jan 2022 18:56:15 -0500 X-MC-Unique: dPxA6w8bMouL0lyByTZMCw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3D30D760C1; Tue, 18 Jan 2022 23:56:14 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.40.192.74]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BFE606AB80; Tue, 18 Jan 2022 23:56:12 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 20INuAAr1998722 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 19 Jan 2022 00:56:10 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20INuAsE1998721; Wed, 19 Jan 2022 00:56:10 +0100 Date: Wed, 19 Jan 2022 00:56:10 +0100 To: Richard Biener <rguenther@suse.de>, Jason Merrill <jason@redhat.com>, Martin Sebor <msebor@gmail.com> Subject: [PATCH] gimple-ssa-warn-access: Fix up asan_test.C -Wdangling-pointer regression [PR104103] Message-ID: <20220118235610.GN2646553@tucnak> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jakub Jelinek <jakub@redhat.com> Cc: gcc-patches@gcc.gnu.org Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
gimple-ssa-warn-access: Fix up asan_test.C -Wdangling-pointer regression [PR104103]
|
|
Commit Message
Jakub Jelinek
Jan. 18, 2022, 11:56 p.m. UTC
Hi! As reported in the PR or as I've seen since the weekend, asan_test.C fails because of many warnings like: /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1162:27: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] ... (lots of them). There are no dangling pointers though, the warning pass sees: some_automatic_var ={v} {CLOBBER}; .ASAN_MARK (POISON, &some_automatic_var, 8); and warns on that (both on user vars and on e.g. TARGET_EXPR temporaries). There is nothing wrong on that, .ASAN_MARK is compiler instrumentation, which doesn't even touch the variable in any way nor make it escaped. What it instead does is change bytes in the shadow memory corresponding to the variable to reflect that the variable is out of scope and make sure that access to it would be diagnosed at runtime. So, for all purposes of the -Wdangling-pointer and -Wuse-after-free warnings, we should ignore this internal call. Bootstrapped/regtested on x86_64-linux and i686-linux, fixes asan_test.C FAIL (so no new test has been added), ok for trunk? 2022-01-18 Jakub Jelinek <jakub@redhat.com> PR middle-end/104103 * gimple-ssa-warn-access.cc (pass_waccess::check_call): Don't check .ASAN_MARK calls. Jakub
Comments
On 1/18/22 16:56, Jakub Jelinek wrote: > Hi! > > As reported in the PR or as I've seen since the weekend, asan_test.C fails > because of many warnings like: > /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] > /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] > /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1162:27: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] > ... > (lots of them). > There are no dangling pointers though, the warning pass sees: > some_automatic_var ={v} {CLOBBER}; > .ASAN_MARK (POISON, &some_automatic_var, 8); > and warns on that (both on user vars and on e.g. TARGET_EXPR temporaries). > There is nothing wrong on that, .ASAN_MARK is compiler instrumentation, > which doesn't even touch the variable in any way nor make it escaped. > What it instead does is change bytes in the shadow memory corresponding > to the variable to reflect that the variable is out of scope and make > sure that access to it would be diagnosed at runtime. > So, for all purposes of the -Wdangling-pointer and -Wuse-after-free > warnings, we should ignore this internal call. > > Bootstrapped/regtested on x86_64-linux and i686-linux, fixes asan_test.C > FAIL (so no new test has been added), ok for trunk? This is in line with what's done for -Wmaybe-uninitialized so it makes sense to do it here as well. -Wmaybe-uninitialized also exempts calls to sanitizer built-ins from checking. I don't know if they might come up here but if it can't be ruled out, moving the code from tree-ssa-uninit.cc into a utility helper and calling it from both places might be a good idea. Martin > > 2022-01-18 Jakub Jelinek <jakub@redhat.com> > > PR middle-end/104103 > * gimple-ssa-warn-access.cc (pass_waccess::check_call): Don't check > .ASAN_MARK calls. > > --- gcc/gimple-ssa-warn-access.cc.jj 2022-01-16 20:55:46.783932110 +0100 > +++ gcc/gimple-ssa-warn-access.cc 2022-01-18 20:56:13.697780325 +0100 > @@ -4232,6 +4232,11 @@ pass_waccess::check_call (gcall *stmt) > if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)) > check_builtin (stmt); > > + /* .ASAN_MARK doesn't access any vars, only modifies shadow memory. */ > + if (gimple_call_internal_p (stmt) > + && gimple_call_internal_fn (stmt) == IFN_ASAN_MARK) > + return; > + > if (!m_early_checks_p) > if (tree callee = gimple_call_fndecl (stmt)) > { > > Jakub >
> Am 19.01.2022 um 01:04 schrieb Martin Sebor via Gcc-patches <gcc-patches@gcc.gnu.org>: > > On 1/18/22 16:56, Jakub Jelinek wrote: >> Hi! >> As reported in the PR or as I've seen since the weekend, asan_test.C fails >> because of many warnings like: >> /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] >> /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] >> /home/jakub/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:1162:27: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=] >> ... >> (lots of them). >> There are no dangling pointers though, the warning pass sees: >> some_automatic_var ={v} {CLOBBER}; >> .ASAN_MARK (POISON, &some_automatic_var, 8); >> and warns on that (both on user vars and on e.g. TARGET_EXPR temporaries). >> There is nothing wrong on that, .ASAN_MARK is compiler instrumentation, >> which doesn't even touch the variable in any way nor make it escaped. >> What it instead does is change bytes in the shadow memory corresponding >> to the variable to reflect that the variable is out of scope and make >> sure that access to it would be diagnosed at runtime. >> So, for all purposes of the -Wdangling-pointer and -Wuse-after-free >> warnings, we should ignore this internal call. >> Bootstrapped/regtested on x86_64-linux and i686-linux, fixes asan_test.C >> FAIL (so no new test has been added), ok for trunk? Ok. Richard > This is in line with what's done for -Wmaybe-uninitialized so it makes > sense to do it here as well. -Wmaybe-uninitialized also exempts calls > to sanitizer built-ins from checking. I don't know if they might come > up here but if it can't be ruled out, moving the code from > tree-ssa-uninit.cc into a utility helper and calling it from both > places might be a good idea. > > Martin > >> 2022-01-18 Jakub Jelinek <jakub@redhat.com> >> PR middle-end/104103 >> * gimple-ssa-warn-access.cc (pass_waccess::check_call): Don't check >> .ASAN_MARK calls. >> --- gcc/gimple-ssa-warn-access.cc.jj 2022-01-16 20:55:46.783932110 +0100 >> +++ gcc/gimple-ssa-warn-access.cc 2022-01-18 20:56:13.697780325 +0100 >> @@ -4232,6 +4232,11 @@ pass_waccess::check_call (gcall *stmt) >> if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)) >> check_builtin (stmt); >> + /* .ASAN_MARK doesn't access any vars, only modifies shadow memory. */ >> + if (gimple_call_internal_p (stmt) >> + && gimple_call_internal_fn (stmt) == IFN_ASAN_MARK) >> + return; >> + >> if (!m_early_checks_p) >> if (tree callee = gimple_call_fndecl (stmt)) >> { >> Jakub >
--- gcc/gimple-ssa-warn-access.cc.jj 2022-01-16 20:55:46.783932110 +0100 +++ gcc/gimple-ssa-warn-access.cc 2022-01-18 20:56:13.697780325 +0100 @@ -4232,6 +4232,11 @@ pass_waccess::check_call (gcall *stmt) if (gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)) check_builtin (stmt); + /* .ASAN_MARK doesn't access any vars, only modifies shadow memory. */ + if (gimple_call_internal_p (stmt) + && gimple_call_internal_fn (stmt) == IFN_ASAN_MARK) + return; + if (!m_early_checks_p) if (tree callee = gimple_call_fndecl (stmt)) {