similar to: [LLVMdev] Semantics of __builtin_setjmp/__builtin_longjmp

Okay. Are you saying that you shouldn't use __builtin functions in general in your program or just __builtin_setjmp/longjmp? Also, are there any warnings issued by either clang or llvm if they are used in your program? On Wed, Apr 27, 2011 at 3:55 PM, Jim Grosbach <grosbach at apple.com> wrote: > The builtins are for internal compiler use in the context of SjLj exception >

The builtins are for internal compiler use in the context of SjLj exception handling. Any other use, including any direct calls of the builtins in user code, are a bad idea with no guaranteed behaviour. That they're exposed at all is, again, for historical purposes. Don't use them. -Jim On Apr 27, 2011, at 3:45 PM, Akira Hatanaka wrote: > Okay. I understand builtin functions do not

I'm trying to make sense in the support for setjmp/longjmp in Clang and LLVM, with only partial success. I'll try to summarize my findings in the hope that someone can shed some light on why things are the way they are and what I'm missing. Clang. Clang recognizes two forms of setjmp (all I say here applies to longjmp similarly): * __builtin_setjmp: gets lowered to calling the

Okay. I understand builtin functions do not have to behave exactly the same way as standard library functions. What I wanted to know is what should the code generated by llvm (clang + llc) look like (I am working on the Mips back-end now). I guess there should be a behavior users expect to see who are using __builtin_setjmp/longjmp even they aren't the same as library functions. If the code

Hi, I'm trying to understand how __builtin_setjmp/longjmp are supposed to interact with the frame pointer on x86_64. In particular, what is the expected behavior when the compiler chooses not to use rsp or rbp to address local variables? When built with Clang, the following program will segfault, but it is fine when built with GCC. The target is x86_64 linux. int main(int argc, char

What would be the best way to convert built-in setjmp and longjmp tp library calls? Should it be implemented in clang or in backends? On Tue, Apr 12, 2011 at 2:38 PM, Jim Grosbach <grosbach at apple.com> wrote: > ARM/Darwin implements them. I'm not aware of any others. > > That said, they are designed for internal use by the compiler for exception > handling. Calling them

On Wed, Apr 27, 2011 at 03:55:53PM -0700, Jim Grosbach wrote: > The builtins are for internal compiler use in the context of SjLj > exception handling. Any other use, including any direct calls of the > builtins in user code, are a bad idea with no guaranteed behaviour. > That they're exposed at all is, again, for historical purposes. Don't use them. Why is longjmp converted

I declared gi2 as "volatile" and I think gi2 is still incremented once. Here is a snippet of the code. Line 39 - 42 increments gi2. According to the standard, shouldn't ++gi2 be executed twice regardless of whether gi2 is volatile or not? Isn't the missing chain from EH_SJLJ_SETJMP node to load/store nodes that access gi2 causing this problem (please see attached file in my

Does the X86 backend (or any other backend) correctly implement support for __builtin_setjmp and __builtin_longjmp? I don't get the correct result when I compile and run the following code with clang. # clang foo.c -O3; ./a.out #include <stdio.h> void *buf[20]; void __attribute__((noinline)) foo (void) { __builtin_longjmp (buf, 1); } int main (int argc, char** argv) { if

There is no C standard to follow for these builtins. You are expecting them to behave as if they were the standard library calls. They are not equivalent and the naming similarity is an unfortunate historical artifact. Use the standard library functions instead. -Jim On Apr 27, 2011, at 1:22 PM, Akira Hatanaka wrote: > I declared gi2 as "volatile" and I think gi2 is still

Hi, I meet an issue when I verify machineinstrs for Powerpc testcases in llvm. llc -mtriple=powerpc64-unknown-linux-gnu < llvm/llvm/test/CodeGen/PowerPC/sj-ctr-loop.ll -verify-machineinstrs Bad machine code: MBB exits via unconditional fall-through but ends with a barrier instruction! *** function: main basic block: %bb.2 for.body.lr.ph (0x100275437e8) Content in block BB.2:

ARM/Darwin implements them. I'm not aware of any others. That said, they are designed for internal use by the compiler for exception handling. Calling them directly like this is very much not recommended. Using the system library setjmp()/longjmp() functions is preferred. -Jim On Apr 12, 2011, at 1:56 PM, Akira Hatanaka wrote: > Does the X86 backend (or any other backend) correctly

On Apr 27, 2011, at 4:08 PM, Joerg Sonnenberger wrote: > On Wed, Apr 27, 2011 at 03:55:53PM -0700, Jim Grosbach wrote: >> The builtins are for internal compiler use in the context of SjLj >> exception handling. Any other use, including any direct calls of the >> builtins in user code, are a bad idea with no guaranteed behaviour. >> That they're exposed at all is,

hi, I'm doing to make llvm backend support sjlj-eh! I have try to use the llvm-IR to generate the sjlj-eh code, but I'm totally despair ! my major problem is that llvm-ir , I mean exception instrinstics are enough for codegen the sjlj-eh code? May I need to modify the llvm-gcc ? or someone can give some advice about llvm-backend 's support sjlj-eh ? best regards

Hi In llvm src the file llvm/lib/Transforms/IPO/LowerSetJmp.cpp, it seems for sjlj-eh ? but this pass has no effect about c++ sjlj-eh. this pass is for future extend? zhangzw

Dear list, I want to add SJLJ exception handling to my frontend. Unfortunately, there doesn't seem to be any examples in the documentation as to how to use the intrinsics @llvm.eh.sjlj.setjmp @llvm.eh.sjlj.longjmp @llvm.eh.sjlj.lsda @llvm.eh.sjlj.callsite Is there a way to force Clang to use SJLJ exception handling for C++? That way I would be able to look at its output to learn how to use

Hi zhangzw, > In llvm src the file llvm/lib/Transforms/IPO/LowerSetJmp.cpp, it > seems for sjlj-eh ? it's not for sjlj-eh. The problem with setjmp/longjmp is that they can jump from one part of a function to any other part, which means that the control-flow graph is pointless; this makes everything more complicated. So how to deal with this? LLVM does have constructs that allow

If you want an automated method, then using the source code re-writer interfaces in clang is probably a reasonable starting place. Just modifying the source code manually is probably easier, though, to be honest. As a moderate caveat to all of this, there are some bits of code out there that use these builtins that are very tightly coupled to the compiler (the Linux kernel used to do this, I

I have another basic question about setjmp/longjmp. When I compile and run the following program, is it expected that global variable gi2 will be incremented twice? It seems that the code generated with clang and llc increments it only once (line 37-43 of attached file). $ clang setjmp6.c -o setjmp6.arm.ll -emit-llvm -O3 -S -ccc-host-triple arm-unknown-darwin -ccc-clang-archs arm $ llc

On Sun, Dec 18, 2016 at 02:23:01PM +0100, Jonas Maebe via llvm-dev wrote: > Recap: we use setjmp/longjmp for our exception handling on all platforms in > our regular (non-LLVM) code generators. I'd like to use the same > infrastructure with the LLVM code generator for code interoperability > purposes (the LLVM SjLj personality is not binary-compatible with our > existing