similar to: [LLVMdev] "UNREACHABLE executed!" error?

The dump from the function I'm running: define %object_structure @0() { entry: ret %object_structure { i8 0, %object_union [double 5.000000e+00, double false] } } the only output I get after the runFunction() call is: UNREACHABLE executed! Stack dump: 0. Running pass 'X86 DAG->DAG Instruction Selection' on function '@0' I just noticed that my union seems to look like

On Aug 15, 2010, at 1:06 PM, Alec Benzer wrote: > What does this error mean? I'm getting it from an ExecutionEngine::runFunction() call. The function I'm passing it was run through verifyFunction() right before the runFunction() call. I can't seem to find anything that tells me what causes this, only specific (but seemingly unrelated to my problem) cases of it happening. Which

Alec Benzer wrote: > The dump from the function I'm running: > > define %object_structure @0() { > entry: > ret %object_structure { i8 0, %object_union [double 5.000000e+00, > double false] } > } Unions are almost entirely unimplemented. Sorry. > the only output I get after the runFunction() call is: > > UNREACHABLE executed! > Stack dump: > 0. Running

Tthe IRBuilder APIs for unions or unions in general? Either way, I was using unions as a temporary solution for a problem I was too lazy to fully figure out anyway. On Sun, Aug 15, 2010 at 4:54 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > Alec Benzer wrote: > >> The dump from the function I'm running: >> >> define %object_structure @0() { >> entry:

The blog post I linked to implied that adding a symbol in the form lle_X_FUNCTIONNAME would allow you to call a function called FUNCTIONNAME. Is this not the case? On Thu, Aug 19, 2010 at 6:46 PM, <o.j.sivart at gmail.com> wrote: > You are adding the symbol as "lle_X_create_number_object" yet your error > message implies you have tried to lookup and use

Alec Benzer <alecbenzer at gmail.com> writes: > Ok, so calling lle_X_FUNCTIONNAME instead of FUNCTIONNAME works (is there > any reason the post used the lle_X_ prefix other than convention? was it > once possible to call external functions as I was originally trying, or, why > did the blog post think it was possible?) AFAIK you can name the function as you please (with some

> I'm afraid that you might be utterly confused about how to use LLVM. Er, I don't think so? I think I was mostly just confused about interfacing with external functions, since whoever wrote that blog post ( http://www.gearleaf.com/blog/post/44) didn't seem to know what he was talking about (or he was doing stuff that once worked but now doesn't? I don't know). If you

Ok, so calling lle_X_FUNCTIONNAME instead of FUNCTIONNAME works (is there any reason the post used the lle_X_ prefix other than convention? was it once possible to call external functions as I was originally trying, or, why did the blog post think it was possible?) I'm now running into trouble when trying to access arguments however. printing args.size() from the function yields

I followed what you said and called verifyModule() with the AbortProcessAction option. verifyModule() returns false, but does not abort and does not print out any information about what caused the verification to fail. Chris Lattner wrote: > On Wed, 21 Feb 2007, Ryan M. Lefever wrote: >> I am writing an interprocedural compiler pass. Because the passneeds >> information from a

I also tried iterating through the functions of the module and calling verifyFunction(), which also returns false, but does not cause an abort or report anything to stderr about what caused the verification to fail. From the doxygen for verifyFunction() and verifyModule(), it seems like they both should print information to stderr if the verification fails and should abort opt if

I am programmatically building some functions in intermediate representation, and trying to verify them, but the verifier always reports that there is a problem, and I can't see why. Minimal test case: #ifdef _MSC_VER #pragma warning(disable : 4141) #pragma warning(disable : 4530) #pragma warning(disable : 4624) #endif #include <llvm/IR/IRBuilder.h> #include <llvm/IR/Verifier.h>

Hi, I'm Ryo Ota. I'm using LLVM 3.8.1. I have a quesion about inlining function in C++ API. I'd like to inline some functions in a module in the same way as `opt -inline` command. But my C++ code didn't work what I want to do. For example, by using `opt -inline` command,`main.ll` is converted into the `inlined.ll`(`opt` command worked what I want to do) [main.ll (Not inlined)]

I think I misread the doxygen. verifyFunction & verifyModule return false if no errors are detected. However, my question now becomes why does the code produced by my transform pass verification, but it causes an assertion failure in the byte reader when it (the code produced by my transform) is passed to another invocation of opt? Ryan M. Lefever wrote: > I also tried iterating

This isn't a strictly llvm-related problem, but I thought I'd ask anyway to see if anyone can help. I'm trying to write a dynamically typed language on top of llvm. My initial idea was to have a general object type for all objects in my language. I came up with: { i8, i8* } the first element of the structure would hold the type of the object, and the second is a pointer to the

Hello everyone: I have a little question about the second argument *action* of verifyFunction. In docs: *Enumerator: * *AbortProcessAction* verifyModule will print to stderr and abort() *PrintMessageAction* verifyModule will print to stderr and return true *ReturnStatusAction* verifyModule will just return true But it still abort when I pass

I'm trying to create a global variable initialized to zero, and return its value from a newly created function, in JIT context. I'm keeping all types as i32 for the moment, and I only have the one module object. This is the code I have for creating the global variable: const Type *type = Type::getInt32Ty(getGlobalContext()); // Constant *zerov = Constant::getNullValue(type); Constant

Is there documentation somewhere on how to call external functions from llvm? The only guide I found was this: http://www.gearleaf.com/blog/post/44, and it doesn't seem to be working for me. I have a function: llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, const std::vector<llvm::GenericValue>& args) { llvm_object_structure* result = new

The title says it all. verifyFunction checks it (Verifier.cpp, line 728). Why can't BasicBlocks that serve as a function's entry point also have predecessors? What keeps a function from looping back to its beginning? Félix -------------- next part -------------- An HTML attachment was scrubbed... URL:

Fair enough. In that case, is there an elegant way to test whether a basic block already has a terminator instruction? (I can think of several ways to do it in the front-end, but all of them are fairly inelegant. The problem I'm trying to solve is things like 'a return instruction needs to be added to the end of a function, if and only if the programmer didn't already end the function

Ah! I didn't know about verifyFunction; it does indeed catch it, thanks! I'll leave that call in my code for all cases for the moment, should help identify problems like that. Is there a recommended way to avoid this problem when compiling a language that has an explicit and optional return statement? On Fri, Feb 5, 2010 at 5:25 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: