From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123648 invoked by alias); 20 Jan 2017 14:27:27 -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 123453 invoked by uid 89); 20 Jan 2017 14:27:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No 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; Fri, 20 Jan 2017 14:27:23 +0000 Received: from smtp.corp.redhat.com (int-mx16.intmail.prod.int.phx2.redhat.com [10.5.11.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 39A5A80462; Fri, 20 Jan 2017 14:27:23 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-250.ams2.redhat.com [10.36.116.250]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D42051D85F3; Fri, 20 Jan 2017 14:27:22 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v0KERIkV023352; Fri, 20 Jan 2017 15:27:19 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v0KERHXn023214; Fri, 20 Jan 2017 15:27:17 +0100 Date: Fri, 20 Jan 2017 14:30:00 -0000 From: Jakub Jelinek To: Martin =?utf-8?B?TGnFoWth?= Cc: Richard Biener , GCC Patches Subject: Re: [PATCH] Speed-up use-after-scope (re-writing to SSA) (version 2) Message-ID: <20170120142717.GT1867@tucnak> Reply-To: Jakub Jelinek References: <4ec48432-9df6-154a-1b13-065b9772cbbf@suse.cz> <20161222172140.GF21933@tucnak> <29d32a7c-a95d-ddb1-d64e-ae8f659d3a4b@suse.cz> <20170116142025.GO1867@tucnak> <7e7f795d-a7a7-584e-8c77-61ea01207c40@suse.cz> <20170117164721.GE1867@tucnak> <20170119163358.GQ1867@tucnak> <5ca02d10-8023-63ea-1669-e5f56f08ec67@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5ca02d10-8023-63ea-1669-e5f56f08ec67@suse.cz> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg01591.txt.bz2 On Fri, Jan 20, 2017 at 03:08:21PM +0100, Martin Liška wrote: > Unfortunately this way would not work as clobber marks content of the memory as uninitialize > is different behavior that just marking a memory can be used (and maybe already contains a value). > > This shows the problem: > > #include > > char cc; > char ptr[] = "sparta2"; > > void get(char **x) > { > *x = ptr; > } > > int main() > { > char *here = &cc; > > for (;;) > { > next_line: > if (here == NULL) > __builtin_abort(); > get (&here); > if (strcmp (here, "sparta") == 0) > goto next_line; > else if (strcmp (here, "sparta2") == 0) > break; > } > } > > With the patch, DSE would optimize out '*here = &cc;' and thus aborts. The problem is definitely > related to goto magic, where we are more defensive in placement of ASAN_MARK(UNPOISON,...). > Hope your optimization is still valid for situations w/o artificial ASAN_MARK(UNPOISON,...) placed due > to goto magic. > > Do we still want to do it now, or postponing to GCC 8 would be better option? I'd still like to resolve it for GCC 7 if at all possible, I think otherwise -fsanitize=address is by default unnecessarily slower (so it is a regression anyway). So, do we always amit ASAN_MARK(UNPOISON, ...) at the start of scope and then yet another ASAN_MARK(UNPOISON, ...) at the goto destination? At least on the above testcase that is the case, so if we say split ASAN_MARK_UNPOISON into something that is used at the start of scope (we'd emit the clobber for those) and others (we would not), then perhaps we could get around that. The above is BTW a clear case where shouldn't emit UNPOISON on the label, as the goto doesn't cross its initialization. But I can see with gotos from outside of some var's scope into it we wouldn't handle it properly. Perhaps for now set some flag/attribute/whatever on vars for which we emit the conservative UNPOISON and never allow those to be made non-addressable (i.e. for those say that POISON/UNPOISON actually makes them always addressable)? Jakub