similar to: [LLVMdev] Linking Errors?

You'll need to include the "support" library to resolve these LeakDetector symbols. You can do this by either placing the path to "support.o" or -lsupport on your link line (in your Makefile). Note that if you use the -l option, you'll likely need to use -L<path> as well to tell the linker where to find "libsupport.a" (file included by the

Ok that works but why on earth would I get a runtime error of: Type.cpp:132: const llvm::Type* llvm::Type::getForwardedTypeInternal() const: Assertion `ForwardType && "This type is not being forwarded to another type!"' failed. Aborted For the line of code: MyModule = new Module( std::string("IDontWork")); > -----Original Message----- > From: llvmdev-admin

I committed: r224058 = 966942da9e68b59c31ce770e7f94c55a63482c6b r224060 = da75f7277e3a129aed8ef8aa4e0d84de40b76fd4 r224061 = f88e4c8e9171045454b2c8e05054c2af8da3fe4f Let me know if somehow you're still hitting the problem. r224061 removes leak detection entirely from `MachineInstr`. There aren't any leaks to be had there, since they're allocated in a custom allocator. They're

On Wed, Dec 10, 2014 at 05:27:45PM -0800, Duncan P. N. Exon Smith wrote: > +zalman at google.com > Hi Duncan, This patch plus another small change fixes the assertion failure for me. With the patch alone, the void* overload of addGarbageObject() was being used by MDNode::getTemporary(), so I had to cast the object as an MDNode*: diff --git a/lib/IR/Metadata.cpp b/lib/IR/Metadata.cpp

> On 2014 Dec 10, at 14:08, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Dec 10, 2014 at 11:21:08AM -0800, Duncan P. N. Exon Smith wrote: >> >>> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: >>> >>> On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >>>> The `Metadata`/`Value`

On Wed, 19 Nov 2003, Reid Spencer wrote: > I have a "first version" of Stacker up and running. Structurally its a > lot like llvm-as. When I run it, I get: > Leaked objects found: after running pass 'Function Pass Manager' > LLVM Value subclasses leaked: This is coming from the LLVM "LeakDetector" stuff. The idea is that you are not supposed to create

> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the >> C++ side of it. This was a rocky day, but I suppose that's what I get >> for failing to stage the change in smaller pieces. >>

Hi Chris, >> In my code generator, I need to prepare a block and add instructions to it, then insert this block in a function defined later (that is I cannot create the function at the beginning stage become some info are not available yet). I tried to create a block without any "parent" (BasicBlock::Create(getGlobalContext(), "init"), fill it, but how to link it with

Hi folk, I get the following stack trace and do have any clue how to fix the problem. 0 opt 0x087ecc99 1 opt 0x087ed265 2 0xb7f6a400 __kernel_sigreturn + 0 3 opt 0x086d4198 llvm::LeakDetector::addGarbageObject(llvm::Value const*) + 29 4 opt 0x0872945f llvm::Instruction::Instruction(llvm::Type const*, unsigned int,

Hi, I finally took the time to track down the remaining memory leaks beside the LeakDetector objects and TypeMaps/ValueMaps I already knew about. It turns out almost all of them came from the command line options module, so I cleaned up the patch for LeakDetector and made a new patch for CommandLine. The patches are attached to this message. That got rid of all but 4 leaks I'm getting,

I am seeing the following assertion in leak detector. /llvm/lib/VMCore/LeakDetector.cpp:43: void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T = void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' failed. I am creating a list of instructions using BuildMI() and adding them to a basic block using BB->insert(). I am seeing this

I have a "first version" of Stacker up and running. Structurally its a lot like llvm-as. When I run it, I get: Leaked objects found: after running pass 'Function Pass Manager' LLVM Value subclasses leaked: Note that the supposed list of "LLVM Value subclasses leaked" is empty. Its followed up by a SIGSEGV at AsmWriter.cpp:754 presumably because I have a BasicBlock

Chris Lattner wrote: > On Feb 15, 2008, at 3:01 PM, John Criswell wrote: > > >>> The convention is that 'remove' unlinks the object from the IR, and >>> 'erase' does remove and deletes the result. >>> >>> If someone wants to clarify this behavior in http://llvm.org/docs/ProgrammersManual.html#common >>> , it would be nice :)

Chris Lattner wrote: >>> If you write your code as an llvm pass, you should automatically get >>> notified of this stuff in a debug build. If you can't do that, >>> manually interfacing to the LeakDetector can help. >>> >>> >> It is an LLVM pass, it's a debug build, and the only assertion I got >> was >> the one in

On Wed, Jun 3, 2009 at 5:10 PM, Manjunath Kudlur <keveman at gmail.com> wrote: > I am seeing the following assertion in leak detector. > > /llvm/lib/VMCore/LeakDetector.cpp:43: > void<unnamed>::LeakDetectorImpl<T>::addGarbage(const T*) [with T = > void]: Assertion `Ts.count(Cache) == 0 && "Object already in set!"' > failed. > > I am

On Feb 15, 2008, at 3:01 PM, John Criswell wrote: >> The convention is that 'remove' unlinks the object from the IR, and >> 'erase' does remove and deletes the result. >> >> If someone wants to clarify this behavior in http://llvm.org/docs/ProgrammersManual.html#common >> , it would be nice :) >> > No, I understood that part (granted, I read

>> If you write your code as an llvm pass, you should automatically get >> notified of this stuff in a debug build. If you can't do that, >> manually interfacing to the LeakDetector can help. >> > It is an LLVM pass, it's a debug build, and the only assertion I got > was > the one in ~Value(). > > Should there have been an earlier assertion? You

This is partly an llvm question, and maybe partly C++. I am trying to make calls on code in the llvm infrastructure.(3.4.2) I appear to be missing some include files, but don't know how to track them down. I get compile errors on existing llvm header files, like the following two examples: -------------------------------------------------------------------------------- In file included

Suppose I have a multi-threaded application that needs to compile many independant bitcodes. All threads do compilation concurrently. For each thread, it creates its own context like the following: LLVMContext *mycontext = new LLVMContext(); But it seems there are still places that explicitly refer to the global context (like in Module.cpp). I wonder wether this is indended or has yet to be

Hi LLVM'ers When linking tblgen tool I get below error message on MinGW. I have put TOOLLINKOPTS=-ldbghelp in Makefile.config. However, when rearranging library dbghelp to the end of the g++ line, tblgen gets linked. -------------------------- make[2]: Entering directory `/C/Projects/build/MinGW/llvm/utils/TableGen' Linking Debug executable tblgen /C/Projects/build/MinGW/llvm/mklib