From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38262 invoked by alias); 8 Nov 2016 09:35:44 -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 37675 invoked by uid 89); 8 Nov 2016 09:35:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2285, risk X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Nov 2016 09:35:42 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id EC0ACABC8; Tue, 8 Nov 2016 09:35:39 +0000 (UTC) Subject: Re: Question about lambda function variables To: Jakub Jelinek References: <20161102101053.GN3541@tucnak.redhat.com> <20161102142028.GQ5939@redhat.com> <8ac49efe-83af-933b-2aa5-f4b22972fa6a@suse.cz> <20161102143511.GV3541@tucnak.redhat.com> <20161104093254.GS3541@tucnak.redhat.com> <0e0fd0f9-1c7d-ac9e-8dfc-9349611b5efe@suse.cz> <59fde5a4-3633-5fc8-daa0-ed485d75a5db@suse.cz> <20161107100815.GG3541@tucnak.redhat.com> <20161108091227.GS3541@tucnak.redhat.com> Cc: Marek Polacek , GCC Patches , jason@redhat.com From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: Date: Tue, 08 Nov 2016 09:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161108091227.GS3541@tucnak.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00691.txt.bz2 On 11/08/2016 10:12 AM, Jakub Jelinek wrote: > On Tue, Nov 08, 2016 at 09:58:13AM +0100, Martin Liška wrote: >> Problematic is lambda function (use-after-scope-ice-1.ii.004t.gimple): >> C::AsyncCloseConnectionWithErrorMsg(const A&):: (const struct __lambda0 * const __closure) >> { >> const struct A message [value-expr: __closure->__message]; >> struct C * const this [value-expr: __closure->__this]; >> >> try >> { >> ASAN_MARK (2, &message, 4); > > That shows that the ASAN_MARK adds the &message without going through > gimplify_expr on it and therefore not handling the DECL_VALUE_EXPR in it, > otherwise it would be > _2 = &__closure->__message; > ASAN_MARK (2, _2, 4); > or something similar. > That said, poisoning/unpoisoning the lambda captured vars inside of the > lambda is of course wrong, 1) you really don't know where the members > live, it could be on the stack, but could very well be on the heap or > elsewhere, and while for stack and say longjmp we are prepared to unpoison > it, for heap allocated vars you risk you keep the memory poisoned in corner > cases and nothing will ever unpoison it; 2) the captured vars live longer > than just in the lambda method, it is perhaps up to whatever function > creates the lambda var to poison/unpoison it. > >> _1 = __closure->__this; >> C::DispatchConnectionCloseEvent (_1, __closure->__message); >> } >> finally >> { >> ASAN_MARK (1, &message, 4); >> } >> } >> >> Where for quite obvious reasons variables 'message' can't be put as a stack variable and ICE is triggered in: >> /tmp/use-after-scope-ice-1.ii:31:23: internal compiler error: in make_decl_rtl, at varasm.c:1311 >> >> My question is how to properly identify local variables defined in __closure context? Is it somehow >> related to DECL_HAS_VALUE_EXPR_P field set on a var? > > So yes, you should just ignore vars with DECL_HAS_VALUE_EXPR_P. That can > mean lots of things (e.g. heavily used for OpenMP/OpenACC/Cilk+), but I > can't think of a case which you would like to poison - if it is > DECL_VALUE_EXPR to another var of part thereof, the other var should still > be declared in its scope. Thank you for clarification, I'm testing patch for this and other fallout issues. Martin > > Jakub >