similar to: Counterintuitive use of LLVMBool in C-API?

Of course, this is normal for C-APIs. But maybe change the name to LLVMResult to propagate the real use? I am not arguing about the results themself. They are standard. But the name is missguiding. As long as it's consistent i know that i have to write an extra record operator in Delphi to reflect this. 2016-09-12 11:11 GMT+02:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On

Okay after translating the headers to Delphi, i found more inconsistencies: > LLVMTypeRef LLVMFunctionType(LLVMTypeRef ReturnType, > LLVMTypeRef *ParamTypes, unsigned ParamCount, > LLVMBool IsVarArg); > In this case it is the other way around. 0 means False and anything else means true :/ (so it acts more like a

Hi LLVM-ers, I am trying to get a return type of a function(from bitcode file) with LLVM-C API, but there seems no appropriate API to do that. I've tried to do that with following code, ---- LLVMModuleRef M; LLVMMemoryBufferRef MemBuf; LLVMValueRef F; // Function LLVMTypeRef RetTy; char *ErrStr; // // -- Load shader module //

Hey there, I'm relatively new to the llvm scene, and so far I'm liking it quite a bit. I'm a bit perplexed as to what llvm-gcc's role is in everything. I've used it to create .bc files for really simple functions and it seems to do quite well at that, but I've been trying to figure out how to take the output from llvm-gcc and actually use it in another program.

Hi Danny, On 2007-12-26, at 15:39, Danny wrote: > I've noticed that the BitcodeReader appears to be an internal > module, but the BitstreamReader is public. Should I be using the > BitstreamReader? If so how. The generic BitstreamReader class is public because it's used in other projects, including clang, to serialize data structures other than LLVM IR. The coding of

That worked quite well. Thank you. One question as a follow up: is there a nice/standard way of including the pre-made bitcode chunks in with the binaries that are being created which read them? Bascially, I'd like to have the same functionality, but rather than having one or more .bc files running around which need to be read at runtime by an executable, moving that into the code

I'm trying to use LLVMGetBitcodeModuleInContext2 to load a .bc file. However, it's not working. The code looks something like this: void llvm_load_IR_library(char *path) { LLVMContextRef global_context; LLVMMemoryBufferRef module_path; LLVMModuleRef ir_lib_module; bool flag; module_path = LLVMCreateMemoryBufferWithMemoryRange(path, strlen(path),

Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =

Oops, missed initializing some stuff. Added: LLVMLinkInMCJIT(); LLVMInitializeNativeTarget(); LLVMInitializeNativeAsmPrinter(); LLVMInitializeNativeAsmParser(); Now it crashes in LLVMGetFunctionAddress(). Hmm. On Wed, Mar 8, 2017 at 5:14 PM, Toshiyasu Morita <toshi at tensyr.com> wrote: > Made it a bit further. Here's the current code: > >

I get a crash when I try to link multiple modules registered in their individual contexts. Documentation for Linker::LinkModules doesn't mention anything about contexts, and the first link succeeds. But the second link crashes. Is this not the right way to merge such modules? If not, then what is the right way? In any case, documentation for Linker::LinkModules should say if contexts are

I would like to use the LLVM-C bindings to provide LLVM access with an OO-design in another language (D), e.g. map from the C API back up to a D API that closely resembles the original C++ API. Since I would like to have D (with its own exception system) to handle the IO, I need a new C API function (unless there is one and I haven't found it): LLVMBool

Hi, I have finished migrating all of the simplify-libcalls pass functionality into instcombine and functionattrs. Now I am ready to completely to remove what is left of the pass from the source tree. However, there are a few C API functions for creating and managing the pass: /** See llvm::PassManagerBuilder::DisableSimplifyLibCalls */ void

Hi David, I'm not certain, but to me the "LLVMSetTarget(module, "i686-apple-darwin11");" line looks suspicious. I'm not familiar with all the ins and outs of how target triples get handled, but it looks to me like that's requesting 32-bit code. I think that if you omit that line completely then the target will be inferred from the execution environment. My best

Hi, I have a IR file generated by Clang: ; ModuleID = 'test_load_lib.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32" target triple = "i686-pc-mingw32" declare i32 @a_outside_func(i32) define i32 @test_func() { entry: %call = call i32

Or do you mean I need to load the module into memory before calling LLVMGetBitcodeModuleInContext2? > Yes, you need to load the module into memory first. > LLVMCreateMemoryBufferWithContentsOfFile will do that for you. Thanks! On Wed, Mar 8, 2017 at 3:48 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/8/2017 3:44 PM, Toshiyasu Morita wrote: > > >>

Hello I quite thank you for your advice,but I have to tell that it made no difference too calling "LLVMAddGlobalMapping(ee,LLVMGetNamedFunction(m,"_a_outside_func"),(void*)(&a_outside_func));". 2014-04-04 16:10 GMT+08:00 Anton Korobeynikov <anton at korobeynikov.info>: > Hello > > While there is a symbol in the object file, there is nothing like this >

oh,I'm sorry to make such a stupid mistake...But I still have to tell the correct one still didnt make difference...so weird 2014-04-04 16:30 GMT+08:00 Anton Korobeynikov <anton at korobeynikov.info>: > Are you sure, that LLVMGetNamedFunction(m,"_a_outside_func") does not > return NULL? I believe it should be > LLVMGetNamedFunction(m,"a_outside_func") >

I noticed that the ocaml compilation isn't using the .opt executables if they're available. We might gain a slight optimization in ocaml compile time by optionally using them with this patch. --- autoconf/configure.ac | 18 +++++ configure | 195 ++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 188 insertions(+), 25 deletions(-) -------------- next part

I was implementing dirty checking for an application, and I found something that is a little counterintuitive. Let me start with a quick quiz: bob=User.find(1) alice=User.find(2) trip=Trip.new trip.driver=bob old_driver=trip.driver trip.driver=alice In this example, who is old_driver? If you guessed Alice, you''re right. Inside associations.rb, the mutator is defined as:

--- bindings/ocaml/llvm/llvm.ml | 2 +- bindings/ocaml/llvm/llvm.mli | 2 +- bindings/ocaml/llvm/llvm_ocaml.c | 2 +- include/llvm-c/Core.h | 32 +++++++++++++++++++------------- 4 files changed, 22 insertions(+), 16 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 316a84e85ed2363551149e65a227c8e7c8192624.diff Type: