similar to: [LLVMdev] SmallVectorTemplateCommon assertion failed

I'm getting an error that I don't know how to fix. I've isolated the input as much as I easily can. I've attached the file that produces the problem. Just calling "llc err.ll -o err.s" generates the error. I'm going to try and isolate even further, but as I'm not sure what I'm looking for I don't know if I'll be successful. Does anybody know what this

I've reduced the example down to a minimum. The error is quite perplexing since the IR appears fine. It is a nonsensical infinite loop now, but that shouldn't be a problem. declare i64 @leaf_exception_personality(i64, i32, i64, i8*, i8*) declare i8* @count_malloc(i64) define internal i8 @junk___init_module_get_args_3() #0 { entry: %_exception = alloca { i8*, i64 } %ignore0 = invoke

I am having some trouble getting my catch clauses to appear as expected in the dwarf exception tables. I have an instruction like this: %0 = landingpad i64 personality i32 (i32, i32, i64, i8*, i8*)* @leaf_exception_personality catch i8* inttoptr (i64 987 to i8*) catch i8* inttoptr (i64 2453 to i8*) In my exception handler I walk through the records. I always get the correct

On 17/10/13 23:57, Bill Wendling wrote: > There shouldn't be any special linker flags you need to use. If > you're getting segfaults, it's probably trying to access the data at > an invalid location or something. Make sure that your EH table is > properly aligned. You might want to hand calculate the values to make > sure that they're correct. What platform are you

On Oct 17, 2013, at 7:24 PM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > On 17/10/13 23:57, Bill Wendling wrote: >> There shouldn't be any special linker flags you need to use. If >> you're getting segfaults, it's probably trying to access the data at >> an invalid location or something. Make sure that your EH table is >> properly aligned. You

I have some exception handling which works fine using the JIT. Now I am producing object files and linking them, but the exception handling tables seem to be missing. I call _Unwind_RaiseException and get _URC_END_OF_STACK as a result. I produce my object file using TargetMachine::addPassesToEmitFile and then I link my resulting files with: gcc -o prog input.o -fexceptions I'm sure I'm

Hi, On 11/04/13 06:06, edA-qa mort-ora-y wrote: > I have some exception handling which works fine using the JIT. Now I am > producing object files and linking them, but the exception handling > tables seem to be missing. I call _Unwind_RaiseException and get > _URC_END_OF_STACK as a result. you will get this if no catch clauses match (eg because there are no catch clauses, perhaps

I'm having trouble understanding the value in the way exceptions are handled on Linux, the dwarf/system V ABI exception spec. The mechanism allows for both cleanup routines and catch handlers, where by cleanup handlers don't stop the search for a normal handler. The personality function (I guess no longer part of the standard, but a C++ thing) can also compare types of the landingpads.

I'm working on exception handling and having some trouble with type information. My personality/types work fine when running in the JIT, but when I produce object files and link them it fails. In particular, from an action record and the LSDA I get a type table entry. The problem is this doesn't appear to be pointing to a valid location. If I derefence it a segfault occurs. Are there

On 03/11/13 12:16, Henrique Santos wrote: > You could try placing a phi node at "defer_block" with incoming value > "result" > when the incoming block is "entry", and do the same for "null" and > "landing". > Then, instead of loading "result", you load the value given by the newly > created phi. That seems like the

Hey edA-qa mort-ora-y, On Sat, Nov 9, 2013 at 6:47 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > I'm getting an error that I don't know how to fix. I've isolated the > input as much as I easily can. I've attached the file that produces the > problem. Just calling "llc err.ll -o err.s" generates the error. > > I'm going to try and isolate

I've having a bit of a problem generating output that doesn't result in the "Instruction does not dominate all uses!". In my code it relates to exception handling and how I generate the blocks. I understand exactly why I get the message, but I'm unsure of how I can structure things to avoid the problem. In a rough pseudo-code, my blocks look like this: entry: store 0,

It was the return type which was i64. I changed it also to my abi_int_size and it works now. I have to take care of a few other type translations, but it looks like MCJIT is working now. Thank you. On 08/11/13 18:12, Yaron Keren wrote: > Something must be wrong with the Function Type. Try to debug into > runFunction to see which if condition fails. > Just a guess, if this is on 64

That makes it more mysterious then since I am indeed only calling a main function. Perhaps I have to invoke it a different way. Here's my call I have now: auto main = linker->getModule()->getFunction( "main" ); std::vector<llvm::GenericValue> args(2); args[0].IntVal = llvm::APInt( platform::abi_int_size, 0 ); args[1].PointerVal = nullptr; llvm::GenericValue gv =

Something must be wrong with the Function Type. Try to debug into runFunction to see which if condition fails. Just a guess, if this is on 64 bit system the first argument type may be int64 but needs to be int32. Yaron 2013/11/8 edA-qa mort-ora-y <eda-qa at disemia.com> > That makes it more mysterious then since I am indeed only calling a main > function. Perhaps I have to invoke

Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get access to the size directly. I know my final compiler will have to get the size itself, but I'm just doing some simple tests directly in assembly now and am hoping there is an easy way to get the size of a

But the incoming value from the landing pad will always be null, won't it? If so, just iterate through the predecessors and add the terminator as the incoming value if it's an invoke instruction and add the null value it's not. Won't that work? On Mon, Nov 4, 2013 at 2:22 AM, edA-qa mort-ora-y <eda-qa at disemia.com>wrote: > On 03/11/13 12:16, Henrique Santos wrote:

On Oct 17, 2013, at 11:35 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > I'm working on exception handling and having some trouble with type > information. My personality/types work fine when running in the JIT, but > when I produce object files and link them it fails. > > In particular, from an action record and the LSDA I get a type table > entry. The

Does this help? http://nondot.org/sabre/LLVMNotes/SizeOf-OffsetOf-VariableSizedStructs.txt On 11 Nov 2012, at 10:52, edA-qa mort-ora-y <eda-qa at disemia.com<mailto:eda-qa at disemia.com>> wrote: Is there a way to get the size of a type in the IR assembly code? I know the size must be known since alloca and getelementptr both implicitly use it, but I don't see any way to get

I'm trying to add some basic exception handling to my language now and I'm uncertain of how I actually start the exception propagation. It appears that "resume" will continue the exception, but I see no mention of how the exception actually starts. If I look at the IR output of a simple C++ program I see that it calls @__cxa_throw, but that is a library function. Somehow I must