similar to: [LLVMdev] Memory leaks after llvm_shutdown

I just copy the latest code in HowToUseJIT and run, but the EngineBuilder(std::move(Owner)).create() keeps return null, any idea why? Here's my CMakeList: cmake_minimum_required(VERSION 3.12) project(llvm_test) set(CMAKE_CXX_STANDARD 14) find_package(LLVM REQUIRED CONFIG) llvm_map_components_to_libnames(llvm_libs support core irreader orcjit native) add_executable(llvm_test main.cpp)

I found a private ErrorStr member, but didn't find the get function of this member, could you tell me how I can get the error message? On Wed, Sep 18, 2019 at 4:02 PM mayuyu.io <admin at mayuyu.io> wrote: > Isn’t there a method in EngineBuilder to get the error message or > something? > I assume it’s you didn’t link in the JIT module > > Zhang > > 在

r172749 removed Linker/LinkArchives.cpp and Linker/LinkItems.cpp citing: This code is dead, and the "right" way to get this support is to use the platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM linker. Could someone please expand on what the "right way" is and these LTO mechanisms or where I can find further information? We used several

Hi Chris, What functions were you using, and what features of them were you using? If you just need to link individual bit codes together, you can do it in exactly the same way that llvm-link does (using Linker::LinkModules). If you really need features like being able to pull objects out of archives, then you should use an LTO enabled linker (either the system linker on OS X, or gold + the gold

Hi, I am using current SVN and in the last week or so, something causing the following assertion failure has changed. void llvm::PATypeHolder::addRef(): Assertion `Ty && "Type Holder has a null type!"' failed. The corresponding stack trace is: #0 0x000000339ec332f5 in raise () from /lib64/libc.so.6 #1 0x000000339ec34b20 in abort () from /lib64/libc.so.6 #2

On Tue, Jul 26, 2011 at 11:01 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 26, 2011, at 8:11 AM, Talin wrote: > > >> If that's true, then it means that we're back to the case where every type >> has to be fully defined down to the leaf level. >> >> >> I'm not sure what you mean. LLVM is perfectly fine with opaque structs

Hi, Reid Spencer wrote: > Call getBytecodeModuleProvider (see Reader.h). The problem is that one needs to provide the filename of the original module as the argument of getBytecodeModuleProvider, whereas this is unknown (it's exactly what we're trying to find out). But, by looking where this method is called in the original bytecode loading process, I figured out a way to set the

I have some patches of my own: * An improvement on Morten's fix to Signals.cpp. * Undo the breakage to system.vcproj (Signals.cpp was being built twice as a result). * Fix a class/struct inconsistency. * Remove unneeded #includes from win32 fSystem files. I've also determined why VC++ complains about deprecated destructors when using hash_map. Because it's not ANSI (yet),

On Mon, 25 Sep 2006, Bram Adams wrote: > Reid Spencer wrote: >> Call getBytecodeModuleProvider (see Reader.h). > The problem is that one needs to provide the filename of the original module > as the argument of getBytecodeModuleProvider, whereas this is unknown (it's > exactly what we're trying to find out). > > But, by looking where this method is called in the

Jeff, On Mon, 2004-11-15 at 21:43, Jeff Cohen wrote: > I have some patches of my own: > > * An improvement on Morten's fix to Signals.cpp. > > * Undo the breakage to system.vcproj (Signals.cpp was being built twice > as a result). > > * Fix a class/struct inconsistency. > > * Remove unneeded #includes from win32 fSystem files. > Thanks for the

Nico, There is a third place that '#undef PPC' is needed (at the top of PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in your CPPFLAGS. I'll try to get this fixed in trunk shortly. -Hal On Fri, 2011-12-02 at 12:30 +0100, acrux_it at libero.it wrote: > hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with > gcc-4.5.3, binutils-2.21.1,

On Fri, 2011-12-02 at 06:58 -0600, Hal Finkel wrote: > Nico, > > There is a third place that '#undef PPC' is needed (at the top of > PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in > your CPPFLAGS. I'll try to get this fixed in trunk shortly. I just tested this, and I was wrong: passing -UPPC to configure in CPPFLAGS does not work for some reason.

hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with gcc-4.5.3, binutils-2.21.1, glibc-2.12.2 . As this suggestion: http://llvm.org/bugs/show_bug.cgi?id=10969 I applied a patch like this one: --- llvm-3.0.src/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h 2011-07-26 01:24:55.000000000 +0200 +++ llvm-3.0.src/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h

llvm-bounces at cs.uiuc.edu wrote: > > ------------------------------------------------------------------------ > > Subject: > Fw: (by sospeng at tom.com)something is wrong , when compiling llvm on debian > From: > "4" <sospeng at tom.com> > Date: > Mon, 29 Aug 2005 20:05:46 +0800 (CST) > To: > llvmdev at cs.uiuc.edu > > To: > llvmdev at

Hi Duncan, But in the doc "Source Level Debugging with LLVM", it shows that llvm 2.6 could get column number. There's an example in the doc as following: http://llvm.org/docs/SourceLevelDebugging.html 1. void foo() { 2. int X = 21; 3. int Y = 22; 4. { 5. int Z = 23; 6. Z = X; 7. } 8. X = Y; 9. } Compiled to LLVM, this function would be represented

On 9/18/2017 8:20 PM, Diptorup Deb via llvm-dev wrote: > Hi, > > We are upgrading an LLVM 4.0-based opt module to LLVM 5.0. After the > upgrade our module works when built with an LLVM Debug build, but > with an LLVM Release build we are encountering the following error. > > This happens after our passes have successfully run. I believe this > has to do with the way our

This is the correct path to the pass: https://github.com/PRUNERS/sword/blob/master/lib/Transforms/Instrumentation/InstrumentParallel.cpp On Mon, May 14, 2018 at 10:06 PM, Simone Atzeni <simone.at at gmail.com> wrote: > Hi all, > > I was porting my pass from LLVM 4.0 to 6.0 and I am getting a segmentation > fault. > I was able to obtain only the info below from GDB. > >

Hi all, I was porting my pass from LLVM 4.0 to 6.0 and I am getting a segmentation fault. I was able to obtain only the info below from GDB. I tried to debug with some printf and the runOnFunction runs correctly. Any idea/suggestion about what is going on? The source code of the pass is here: https://github.com/PRUNERS/sword/blob/master/lib/Sword.cpp Any help is much appreciated, Thanks!

Hi, We are upgrading an LLVM 4.0-based opt module to LLVM 5.0. After the upgrade our module works when built with an LLVM Debug build, but with an LLVM Release build we are encountering the following error. This happens after our passes have successfully run. I believe this has to do with the way our passes are registered. Would greatly appreciate some pointers, as to where to look. Program

I''m not sure if this is even possible, but here is my current method: class Item < ActiveRecord::Base def self.generate(name) Item.create(:name => name) || nil end end class ItemController < ActionController::Base layout "application" def index @items = Item.find(:all) end def create if @request.method ==:post name = @params[:name]