From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123874 invoked by alias); 26 Feb 2015 16:55:16 -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 123863 invoked by uid 89); 26 Feb 2015 16:55:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 26 Feb 2015 16:55:15 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1QGtEUH001648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 26 Feb 2015 11:55:14 -0500 Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1QGtBjU009297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Feb 2015 11:55:13 -0500 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t1QGt4ZN018711; Thu, 26 Feb 2015 13:55:05 -0300 From: Alexandre Oliva To: Jakub Jelinek Cc: Richard Biener , GCC Patches Subject: Re: [PR58315] reset inlined debug vars at return-to point References: <20150225161256.GT1746@tucnak.redhat.com> <20150225212231.GX1746@tucnak.redhat.com> Date: Thu, 26 Feb 2015 17:16:00 -0000 In-Reply-To: (Alexandre Oliva's message of "Wed, 25 Feb 2015 21:01:09 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2015-02/txt/msg01632.txt.bz2 On Feb 25, 2015, Alexandre Oliva wrote: > if a function is called within a loop and we inline it, bindings from > the call in one iteration of the loop will carry over onto the > subsequent iteration until a new binding occurs. Wait, I have to take that back and revisit the code I looked at. var-tracking handles confluences differently between VTA-tracked and old-style var-tracking vars, and I was probably confused by that: it occurred to me this morning that confluence points of VTA-tracked variables perform a set intersection, whereas old-style VTA performs set union across locations at all incoming edges. So, what I have concluded should only apply to old-style var-tracking vars, or to VTA-tracked vars in unrolled loops whose intermediate conditions were optimized out (so that there isn't any confluence with incoming edges without bindings for the var). I'm afraid I'll have to look again and figure out what I got wrong. Apologies for the noise. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer