[PATCH] ignore --disable-free in clang when leak detection is enabled

[Kostya Serebryany]

On Fri, Dec 27, 2013 at 12:21 AM, Chandler Carruth <chandlerc at gmail.com>wrote:

>
> On Thu, Dec 26, 2013 at 2:29 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> >> Isn't clang multithreaded? What about synchronization?
>>   no (afaict)
>>   If it ever becomes multithreaded, we can guard the push_backs by a
>> mutex (will add a tiny bit of ugliness)
>
>
> I think we could probably do a lot cheaper than a vector at least for the
> common case -- we know we will *never* need to traverse this, and it will
> probably be relatively small (at least, I hope...).
>
> I would compile some big single source files (single-source gcc, some
> super big C++ code, etc.) with a hack that prints out how many free() calls
> are being omitted via this flag. If the number is O(10000) I would probably
> do something kinda horrible:
>
I expect it to be more like ~10 than ~10000. Remember we don't need to
store all leaked heap objects there, only the roots.

>
> """
> static const unsigned NumPointersPerGraveYard = ((1 << 16) /
> sizeof(void*)) - 1;
>

But this is so much more code than a single vector!?
(And I like the naming!)


> static unsigned GraveYardIndex = 0;
> struct PointerGraveYard {
>   void *DeadPtrs[NumPointersPerGraveYard];
>   PointerGraveYard *PrevGraveYard;
> } InitialGraveYard, *CurrentGraveYard = &InitialGraveYard;
>
> void BuryPointer(void *p) {
>   PointerGraveYard *G = CurrentGraveYard;
>   if (GraveYardIndex >= NumPointersPerGraveYard) {
>     CurrentGraveYard = new PointerGraveYard;
>     CurrentGraveYard->PrevGraveYard = G;
>     G = CurrentGraveYard;
>     GraveYardIndex = 0;
>   }
>
>   G->DeadPtrs[GraveYardIndex++] = p;
> }
> """
>
> This seems likely to be way cheaper than the vector in all of the common
> cases. I'm not really worried about the size of the static global either
> because it would be mapped by the loader rather than taking up actual data
> size in the binary.
>
> -Chandler
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131227/745a5888/attachment.html>