From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101257 invoked by alias); 2 Nov 2016 12:56:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 100493 invoked by uid 89); 2 Nov 2016 12:56:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=re-structure, clobbers, asan_poision, ASAN_POISION X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Nov 2016 12:56:16 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 635B131B332; Wed, 2 Nov 2016 12:56:15 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-19.brq.redhat.com [10.40.204.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA2CuD5L010183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 2 Nov 2016 08:56:14 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id uA2CuCZM011261; Wed, 2 Nov 2016 13:56:12 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id uA2Cu9E2011031; Wed, 2 Nov 2016 13:56:09 +0100 Date: Wed, 02 Nov 2016 12:56:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Martin =?utf-8?B?TGnFoWth?= , GCC Patches Subject: Re: [PATCH, RFC] Introduce -fsanitize=use-after-scope (v2) Message-ID: <20161102125609.GQ3541@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20161007111347.GF7282@tucnak.redhat.com> <20161021142617.GG7282@tucnak.redhat.com> <3a109250-0440-7438-8e1f-7e5c6d8b6580@suse.cz> <20161027172358.GN3541@tucnak.redhat.com> <606cd948-6cba-02a4-f114-35900ab53203@suse.cz> <20161101151219.GT3541@tucnak.redhat.com> <20161102095202.GL3541@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00162.txt.bz2 On Wed, Nov 02, 2016 at 01:36:31PM +0100, Richard Biener wrote: > > Unless I'm missing something we either need to perform further analysis > > during the addressable subpass - this variable could be made > > non-addressable, but is used in ASAN_MARK, would if we rewrote it into SSA > > form there be any SSA uses of the poisoning ASAN_MARK? If yes, keep it > > addressable, otherwise rewrite into SSA. > > Or, just rewrite it into SSA always, but turn the poisoning ASAN_MARK into > > some new internal ECF_CONST call var_5 = ASAN_POISON (); and if we have any > > uses of those, rewrite it back into addressable immediately or later or > > something. > > Or just give up optimizing (asan has a penalty anyway)? Or Well, asan has a penalty and -fsanitize-use-after-scope even bigger penalty, but the point is to make that penalty bearable. > re-structure ASAN_POISON () > similar to clobbers: > > var = ASAN_POISION (); > > that avoids the address-taking and thus should be less heavy-weight on > optimizations. Yeah, that is what I meant. The issue is how to report uses of such SSA_NAME when there is no memory. So, either we'd need a special runtime library entrypoint that would report uses after scope even when there is no underlying memory, or we'd need to force it at asan pass time into memory again. Jakub