This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch ping


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]