From patchwork Fri Jan 20 14:34:29 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Markus Trippelsdorf X-Patchwork-Id: 717750 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3v4jsW0FjXz9sCg for ; Sat, 21 Jan 2017 01:34:54 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="KYWjzwKq"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; q=dns; s= default; b=P34nSJqjtSMdoPLC1wm5NiEuq6cTkhK0L8K+uyg/pdFnpynd4ukVS oy5gMGBEqBPuQ0S58sylhh82qFF+JO15xRvD0WohYniqjrldnSraSyu1Z1GzQUuf Z0FJEY5PTframVFtd6JraR0yCp2MbqIAaMZ7qAQTvTPWf9QoE9VWF8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=default; bh=cyQu0I9R3PS/jr4oF+dpyFiAe+k=; b=KYWjzwKqjqzU2Q97K7G8FgH0/fk9 G0dymDVtpDHhq5pEcxCdZ9DBvfTztB/jG9GDvT97JwZWUxSkOqBAjbun1V6oTmaT ZVXm/n8/1OZbulhJzdu4s0k5YNcgKYf+4VGoWEyrDiCwZgAqSn4q26EARjbKF4Pp WVJAVatnZHvuBC0= Received: (qmail 28867 invoked by alias); 20 Jan 2017 14:34:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 28712 invoked by uid 89); 20 Jan 2017 14:34:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: mail.ud10.udmedia.de Received: from ud10.udmedia.de (HELO mail.ud10.udmedia.de) (194.117.254.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Jan 2017 14:34:34 +0000 Received: (qmail 22503 invoked from network); 20 Jan 2017 15:34:30 +0100 Received: from ip5b405f78.dynamic.kabel-deutschland.de (HELO x4) (ud10?360p3@91.64.95.120) by mail.ud10.udmedia.de with ESMTPSA (ECDHE-RSA-AES256-SHA encrypted, authenticated); 20 Jan 2017 15:34:30 +0100 Date: Fri, 20 Jan 2017 15:34:29 +0100 From: Markus Trippelsdorf To: Jakub Jelinek Cc: Martin =?utf-8?B?TGnFoWth?= , Richard Biener , GCC Patches Subject: Re: [PATCH] Speed-up use-after-scope (re-writing to SSA) (version 2) Message-ID: <20170120143429.GA13630@x4> References: <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> <20170120142717.GT1867@tucnak> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20170120142717.GT1867@tucnak> On 2017.01.20 at 15:27 +0100, Jakub Jelinek wrote: > 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). Another possibility would be to disable use-after-scope for gcc-7 (like LLVM) and re-enable it for gcc-8. diff --git a/gcc/opts.c b/gcc/opts.c index 5f573a16ff15..2664b54133e4 100644 --- a/gcc/opts.c +++ b/gcc/opts.c @@ -993,7 +993,7 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set, enabled. */ if ((opts->x_flag_sanitize & SANITIZE_USER_ADDRESS) && !opts_set->x_flag_sanitize_address_use_after_scope) - opts->x_flag_sanitize_address_use_after_scope = true; + opts->x_flag_sanitize_address_use_after_scope = false; /* Force -fstack-reuse=none in case -fsanitize-address-use-after-scope is enabled. */