From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25023 invoked by alias); 13 Feb 2018 15:22:34 -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 24429 invoked by uid 89); 13 Feb 2018 15:22:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=scared X-HELO: mail-wm0-f52.google.com Received: from mail-wm0-f52.google.com (HELO mail-wm0-f52.google.com) (74.125.82.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Feb 2018 15:22:32 +0000 Received: by mail-wm0-f52.google.com with SMTP id j21so13719423wmh.1 for ; Tue, 13 Feb 2018 07:22:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LTChStPpvClzhV6ID6QbpymN+mM2W+GDLCMaift0KBw=; b=r1M8158yR05T7g7+QuaxDa4tIQcsmhhvlMJMCb1EqPqZQ3GOsQPnJi1fjxI6PTmqOC TvIODMciYcjqvuKiIS1+ix1CjaIogDnEGfbXrF5iJTnrP6NCaYvwVhHWw3YdFwM+EMdy YFKAOp9upwiKr/4K9RORi28tv2lVB9ZjZlybVZI/lep7dlf8waGjwaxQm5pL5fJ4iFgn huUTStFKw52DeZl6pkTNlqLn0SOrQ+iJJp7sEQ1s869YiFNtk8woRuO8u8oE4bLcrL3Y HhhN88N3RVt+OOgcdJg3bmFTZmC5iI+zR3Kcmr9u6kfu/J8frcI3YIQn3vo4mo1ds+L/ JK0g== X-Gm-Message-State: APf1xPClr0VxEO6fSFTl14rj/h/b/ft8VHpSWjTfBlqxcEeqacQ91fnQ wFUMN48y+KkQNsXk9WD2pIc= X-Google-Smtp-Source: AH8x227UGLqZJA3Z5i7+woicUsaLhvOmKsp+K0N/IH36J33ERN2qn51Z5ipSpkYP6CLT6nQRmH9uew== X-Received: by 10.28.130.72 with SMTP id e69mr1716844wmd.50.1518535349725; Tue, 13 Feb 2018 07:22:29 -0800 (PST) Received: from [192.168.10.165] ([82.84.102.245]) by smtp.googlemail.com with ESMTPSA id 41sm7835028wrc.12.2018.02.13.07.22.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 07:22:28 -0800 (PST) Subject: Re: Fallout: PR84340 To: Jakub Jelinek Cc: =?UTF-8?Q?Martin_Li=c5=a1ka?= , Richard Biener , GCC Patches , marcandre.lureau@redhat.com References: <2bd36577-88f0-2926-d777-ee9a11d315f4@gnu.org> <4FD5AE20-78E2-4741-A6CB-EA2B0AA3514F@gmail.com> <20180209180745.GK5867@tucnak> <51F0785D-7117-447E-9D49-BD76CA47FC45@gmail.com> <565904f6-cab7-b52c-5004-d604c01eeca9@gnu.org> <5673a4f3-34eb-1c46-6f50-c7094d683929@suse.cz> <44608c92-4768-43d5-e95d-308687def774@gnu.org> <20180213112155.GP5867@tucnak> <20180213133504.GA5866@tucnak> From: Paolo Bonzini Message-ID: <0a59a69d-a177-65ed-8f69-1a1ab4666594@gnu.org> Date: Tue, 13 Feb 2018 15:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180213133504.GA5866@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-02/txt/msg00733.txt.bz2 On 13/02/2018 14:35, Jakub Jelinek wrote: > On Tue, Feb 13, 2018 at 12:21:55PM +0100, Jakub Jelinek wrote: >> On Tue, Feb 13, 2018 at 12:15:36PM +0100, Paolo Bonzini wrote: >>> The issue is that the ASAN_CHECK doesn't exist at early DSE time, and >>> thus causes the store to disappear. >> >> If it was DSE removing the stores before asan pass, then it would FAIL >> before as well. > > Sorry, while ASAN_CHECK is introduced late, ASAN_MARK is present there > already from the gimplification. Yeah, and it keeps everything alive. > For use after scope, I guess a lot of the stores after end of scope > (rather than reads) are something DSE could consider removing. > So, shall we just disable DSE on vars where their address "escapes" > through ASAN_MARK when -fsanitize-address-use-after-scope? But the stores _are_ dead; it's only the ASAN_CHECK that isn't. Hence the idea of doing the entire instrumentation very early. > Generally, dead stores could be eliminable when stored before the > corresponding ASAN_MARK poison (but even ASAN_MARK with "..W.." will > prevent those) and uneliminable when stored after ASAN_MARK poison. > > For the "fn spec" for now, I'd just go with "..R.." for ASAN_CHECK and > NULL for ASAN_MARK for now. I'm a bit scared of that even, :) especially in stage4. If you think it's safe enough, I can give it a shot, but honestly I wouldn't have much time to deal with the fallout now (hence the quick revert). Paolo