similar to: [LLVMdev] Static destructor problem with recent HEAD

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"

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

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 +

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

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

Pete Cooper and I have been looking 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

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

> 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

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

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

In various debug dumps (eg., Clang's -ast-dump), various objects (eg., Stmts and Decls in that -ast-dump) are identified by pointers. It's very reliable in the sense that no two objects would ever have the same pointer at the same time, but it's unpleasant that pointers change across runs. Having deterministic identifiers instead of pointers would aid debugging: imagine a

On Sun, Sep 5, 2010 at 1:02 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > > I've carefully studied the source code of CGDebugInfo in clang as a > working > > example. One puzzlement is that there's a discrepancy between what the > > "source level debugging with LLVM" docs

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

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 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

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!

Hi, I replaced the MMTk code with a C-version MMTk code (I have been working on such AOT compiler for a while). The compiler should deal with most of the MMTk code base correctly - at least I get marksweep running with a tiny client). So I am trying to put the C version MMTk back with VmKit. I tried not to change much existing code except where necessary, such as name mangling and MMTkObject

This is a great idea! I personally also wouldn't mind going further in debug builds and actually create and store sequential IDs with the objects and take the small memory hit for improved debuggability. The `PersistentId` field in SelectionDAG works that way and has helped make the output more readable IMO. - Matthias > On Aug 28, 2018, at 5:22 PM, George Karpenkov via llvm-dev

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

> On Mar 28, 2016, at 6:02 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Mar 28, 2016, at 3:12 PM, Chandler Carruth <chandlerc at google.com <mailto:chandlerc at google.com>> wrote: >> >> FWIW, I agree with Mehdi that we should just assert that our types don't get called with size zero. > Yeah, I agree. I’ve