search for: bumpptrallocators

On Sat, Oct 15, 2011 at 9:49 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > >> I recently updated my version of LLVM from revision 140108 to 142082, and >> several things broke, most of which were easily fixed. However, I'm now >> getting a "pure virtual method called"

Interestingly, I also get a similar error in a different executable (my unittest): pure virtual method called terminate called without an active exception 0 tartc 0x00000001010a8265 PrintStackTrace(void*) + 53 1 tartc 0x00000001010a88cc SignalHandler(int) + 364 2 libSystem.B.dylib 0x00007fff831341ba _sigtramp + 26 3 libSystem.B.dylib 0x7261742e65637365 _sigtramp +

I'll preface by saying I'm new to LLVM - I noticed there is an efficient BumpPtrAllocator - however, I can't figure out how I can allocate IR objects using that allocator. It looks like all the factory methods use regular new/delete. I'm sure someone BumpPtrAllocator is there for a good reason, and someone here has thought of this use case before. Anyone want to comment? Is

Hi, I was having a little trouble installing clang.... while llvm installs properly but clang gives this error on invoking make in Clang make[2]: Leaving directory `/home/na2271/Desktop/llvm-2.3-x/tools/clang/lib/Headers' make[2]: Entering directory `/home/na2271/Desktop/llvm-2.3-x/tools/clang/lib/Basic' llvm[2]: Compiling SourceManager.cpp for Release build SourceManager.cpp: In member

I recently updated my version of LLVM from revision 140108 to 142082, and several things broke, most of which were easily fixed. However, I'm now getting a "pure virtual method called" exception (__cxa_pure_virtual) which I wasn't getting before. This is happening in the destructor of a statically-initialized object. (More precisely, it's blowing up in a BumpPtrAllocator,

On Sat, Oct 15, 2011 at 9:20 PM, Talin <viridia at gmail.com> wrote: > I recently updated my version of LLVM from revision 140108 to 142082, and > several things broke, most of which were easily fixed. However, I'm now > getting a "pure virtual method called" exception (__cxa_pure_virtual) which > I wasn't getting before. This is happening in the destructor of

Hi Ted, Doug said you might have a clang-based checker that would detect when people allocate memory with a BumpPtrAllocator and then construct a class into it that needs destruction. In killing valgrind-found memory leaks in LLVM, I've found several instances of this mistake. They often involve SmallVectors, which only show up as leaks in valgrind if they happen to overflow their static

Hi all (No idea if I have the correct audience. Please CC more people as needed). I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. The problem is that lld requests that we StringRef::copy an empty string. This passes a length of 0 to a BumpPtrAllocator. The BumpPtrAllocator happened to not have anything allocated yet so the CurPtr is nullptr, but given that we need 0 space we think

...at memory profiles of running llc on verify-uselistorder.lto.opt.bc (ld -save-temps dump just before CodeGen of building verify-uselistorder with -flto -g). I've attached leak-backend.patch, which we're using to make Intrustruments more accurate (instead of effectively leaking things onto BumpPtrAllocators, really leak them with malloc()). (I've collected this data on top of a few not-yet-committed patches to cheapen `MCSymbol` and `EmitLabelDifference()` that chop around 8% of memory off the top, but otherwise these numbers should be reproducible in ToT.) The `DIE` class is huge. Directly, it...

...t what offset the object is in that slab. Therefore it is possible to identify the object by its (slab index, offset) pair. Eg., "TypedefDecl 0:528" (you already memorized it) instead of "TypedefDecl 0x7f80a28325e0". This could be applied to all sorts of objects that live in BumpPtrAllocators. In order to compute such identifier, we only need access to the object and to the allocator. No additional memory is used to store such identifier. Such identifier would also be persistent across runs as long as the same objects are allocated in the same order, which is, i suspect, often the...

> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in

...nd at what offset the object is in that slab. Therefore it is possible to identify the object by its (slab index, offset) pair. Eg., "TypedefDecl 0:528" (you already memorized it) instead of "TypedefDecl 0x7f80a28325e0". This could be applied to all sorts of objects that live in BumpPtrAllocators. >> >> In order to compute such identifier, we only need access to the object and to the allocator. No additional memory is used to store such identifier. Such identifier would also be persistent across runs as long as the same objects are allocated in the same order, which is, i suspe...

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a BumpPtrAllocator. The

\tools\clang\tools\CIndex && D:\Tools\Building\cmake\bin\cmake.exe -E cmake_link_script CMakeFiles\CIndex.dir\link.txt --verbose=1 D:\Tools\Building\gcc\bin\g++.exe -shared -o ..\..\..\..\bin\libCIndex.dll -Wl,--out-implib,..\..\..\..\lib\libCIndex.dll.a -Wl,--major-image-version,0,--minor-image-version,0 CMakeFiles\CIndex.dir\CIndex.cpp.obj ..\..\..\..\lib\libLLVMMC.a

On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi all > > (No idea if I have the correct audience. Please CC more people as needed). > > I have an UBSan failure in BumpPtrAllocatorImpl.Allocate. > > The problem is that lld requests that we StringRef::copy an empty string. > This passes a length of 0 to a

Hi llvmdev! In our project (Windows, Visual Studio compiler) we've got some frontend which generates LLVM IR. Now I'm observing strange *llvm_shutdown* behavior. If I called it when I was done using the LLVM APIs I saw that destructors of static objects created new ManagedStatic objects, which was never freed. Then I tried to use static global llvm_shutdown_obj to cause destruction

> On Mar 22, 2016, at 5:39 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 22, 2016, at 5:35 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: >> >> >> >> On Tue, Mar 22, 2016 at 5:30 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at

FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. That said, I don't think we can be terribly cavalier with what we expect from standard allocator types, operator new, or malloc. And so I would expect LLVM_ATTRIBUTE_RETURNS_NOALIAS to not imply NONNULL, and while it seems reasonable to put NONNULL on *our* allocate function because of the

On Aug 7, 2010, at 7:05 PM, Steven Noonan wrote: > I've been doing work on memory reduction in Unladen Swallow, and > during testing, LiveRanges seemed to be consuming one of the largest > chunks of memory. That's interesting. How did you measure this? I'd love to see your data. Note that the LiveRange struct is allocated by a plain std::vector, and your patch doesn't

Hi all， Clang use a hash table to store all its identifiers. The hash table definition is: typedef llvm::StringMap<IdentifierInfo*, llvm::BumpPtrAllocator> HashTableTy; HashTableTy HashTable; Can anyone explain the mechnism of handling the name string key collision for me? Is there a IdentifierInfo objects chain or list for variable or function with the same name? Thanks very much!