From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13421 invoked by alias); 5 Mar 2013 13:47:31 -0000 Received: (qmail 13408 invoked by uid 22791); 5 Mar 2013 13:47:28 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_VB X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Mar 2013 13:47:22 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r25DlMxT007685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Mar 2013 08:47:22 -0500 Received: from zalov.cz (vpn1-7-229.ams2.redhat.com [10.36.7.229]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r25DlKRO019248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Mar 2013 08:47:21 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.cz (8.14.5/8.14.5) with ESMTP id r25DlIGC010224; Tue, 5 Mar 2013 14:47:18 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r25DlHvn010222; Tue, 5 Mar 2013 14:47:17 +0100 Date: Tue, 05 Mar 2013 13:47:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: Vladimir Makarov , Tom Tromey , Jeff Law , gcc-patches@gcc.gnu.org Subject: Re: Patch ping Message-ID: <20130305134717.GI12913@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20130305131224.GH12913@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 X-SW-Source: 2013-03/txt/msg00179.txt.bz2 On Tue, Mar 05, 2013 at 02:26:03PM +0100, Richard Biener wrote: > On Tue, 5 Mar 2013, Jakub Jelinek wrote: > > Thanks for all the recent reviews of memory leak plugging patches, > > there are 4 still unreviewed from last week though. > > > > - sched-deps leak fix: > > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01197.html > > > > - LRA leak fix: > > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01239.html > > > > - libcpp leak fix: > > http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01341.html > > > > - PCH leak fix + --enable-checking=valgrind changes to allow > > --enable-checking=yes,valgrind bootstrap to succeed: > > http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00044.html > > That looks awkward ... isn't there a simple valgrind_disable () / > valgrind_enable () way of disabling checking around this code? Unfortunately not. I went through all valgrind.h and memcheck.h client calls. If at least there was a VALGRIND_GET_VBITS variants that allowed getting all vbits, (i.e. whether something is unaddressable vs. undefined vs. defined), rather than just if any of the vbits are unaddressable, give up, otherwise return undefined vs. defined bits, it would simplify the code. I hope perhaps future valgrind version could add that, so it would be just VALGRIND_GET_VBITS2, VALGRIND_MAKE_MEM_DEFINED before and VALGRIND_SET_VBITS2 at the end (restore previous state). I've at least added __builtin_expect, so the binary search code isn't in hot path. It isn't that slow, during binary search I'm always testing just a single byte, and say if we don't have any single memory allocations > 4GB, it will be at most 37 valgrind client calls per objects, usually much smaller number than that. Jakub