search for: __builtin_setjmp

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 i...

Hi all, currently we lower the __builtin_setjmp/__builtin_longjmp intrinsincs to SjLj exception style intrinsics. For ARM on non-Darwin, they end up as nops, breaking Ruby. This leads to the question of what the defined semantics of them is. (a) Are they supposed to be compatible with libc? PPC disagrees in comments. (b) Are they supposed to b...

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 (...

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 > handling. Any other use,...

...piler 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 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...

...nderstand 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 generated by arm-darwin is acceptable, does it mean that you can freely move code that accesses a global variable above the call to setjmp? On Wed, Apr 27, 2011 at 2:03 PM, Jim Grosbach <grosbach at apple.com> wrote: &g...

...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 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...

...nderstand 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 generated by arm-darwin is acceptable, does it mean that you can freely move code that accesses a global variable above the call to setjmp? > > On Wed, Apr 27, 2011 at 2:03 PM, Jim Grosbach <grosbach at apple.com>...

...stdio.h> > #include <stdlib.h> > void *buf[20]; > > int gi2 = 0; > > > void __attribute__ ((noinline)) sub2 (void) > { > __builtin_longjmp (buf, 1); > > } > > int > main (int argc, char **argv) > { > int n = atoi (argv[1]); > int r = __builtin_setjmp (buf); > ++gi2; > > if (r) > { > printf ("setjmp %d\n", n + gi2); > return 0; > } > > sub2 (); > > return 0; > } > > > On Wed, Apr 13, 2011 at 10:05 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > &gt...

....h> > #include <stdlib.h> > void *buf[20]; > > int gi2 = 0; > > > void __attribute__ ((noinline)) sub2 (void) > { > __builtin_longjmp (buf, 1); > > } > > int > main (int argc, char **argv) > { > int n = atoi (argv[1]); > int r = __builtin_setjmp (buf); > ++gi2; > > if (r) > { > printf ("setjmp %d\n", n + gi2); > return 0; > } > > sub2 (); > > return 0; > } > > > On Wed, Apr 13, 2011 at 10:05 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: &g...

...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 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...

...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 llvm.sjlj.setjmp intrinsic * setjmp() library call does not appear to be handled specially, although a no-longer-comment in a test I removed in r181468 said: "__builtin_longjmp/setjmp should get transformed into llvm.setjmp/longjmp > just like explicit setjmp/...

...n-darwin -ccc-clang-archs arm $ llc setjmp6.arm.ll -o setjmp6.arm.s #include <stdio.h> #include <stdlib.h> void *buf[20]; int gi2 = 0; void __attribute__ ((noinline)) sub2 (void) { __builtin_longjmp (buf, 1); } int main (int argc, char **argv) { int n = atoi (argv[1]); int r = __builtin_setjmp (buf); ++gi2; if (r) { printf ("setjmp %d\n", n + gi2); return 0; } sub2 (); return 0; } On Wed, Apr 13, 2011 at 10:05 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Apr 13, 2011, at 9:51 AM, Akira Hatanaka wrote: > > > i...

On Apr 13, 2011, at 9:51 AM, Akira Hatanaka wrote: > int > main (int argc, char** argv) > { > int n = atoi(argv[1]), r; > > if ((r = setjmp (buf))) > { > printf("n = %d\n", n); > return 0; > } Non-volatile local variables are not preserved by setjmp(), so this program can print whatever it wants. /jakob

Hi, I'm trying to implement __builtin_setjmp / __builtin_longjmp for Sparc processors. I think I'm very close, but I can't work out how to issue BuildMI-type instructions to load the address of the recovery location (set in setjmp) into a register using the SETHI / OR combination. I can't see any equivalent code anywhere else in S...

...IPRA capability so that internal function calls might avoid this reconfiguration if the necessary configuration is always done in the caller? [Yuanke] I don't know IPRA capability and I am very interesting on it. Would you post some linkage that introduce IPRA? How will the implementation of __builtin_setjmp/longjmp be affected? [Yuanke] That depends on the ABI. We propose all tile register is caller saved, so I think setjmp/longjmp is not affected. Thanks again, Hal 9. Use recommendation Due to the shape configure issue, we recommend user to define the tile shape at the entry of the functi...

..._setjmp". And there doesn't seem to be any provision for returning the current value of the volatile variable v if setjmp returns non-zero - the bitcode always returns zero, whereas the spec for setjmp() says that f() should return 1 if g() does a longjmp(). If I change my program to call __builtin_setjmp() explicitly, instead of setjmp(), the resulting bitcode has optimised the call away as if it always returned zero. So is setjmp supported at all with llvm-gcc4? I couldn't see anything in the release notes saying that it isn't. Thanks, Jay. -------------- next part -------------- An HTML...

...", "n") BUILTIN(__builtin_extract_return_addr, "v*v*", "n") BUILTIN(__builtin_frame_address, "v*IUi", "n") +BUILTIN(__builtin_stack_pointer, "v*", "n") BUILTIN(__builtin_flt_rounds, "i", "nc") BUILTIN(__builtin_setjmp, "iv**", "j") BUILTIN(__builtin_longjmp, "vv**i", "r") diff --git a/lib/CodeGen/CGBuiltin.cpp b/lib/CodeGen/CGBuiltin.cpp index d187678..f66f506 100644 --- a/lib/CodeGen/CGBuiltin.cpp +++ b/lib/CodeGen/CGBuiltin.cpp @@ -736,6 +736,11 @@ RValue CodeGenFunctio...

Hi, I'm implementing __builtin_setjmp and __builtin_longjmp for Sparc 32 bit processors (64 bit later, time allowing). I'm basing the code on the PowerPC version, which itself is based on the X86 version. This code is very nearly working, and I've had it working for -O0 optimisation (with a slightly different version to that...

Hi, Intel Advanced Matrix Extensions (Intel AMX) is a new programming paradigm consisting of two components: a set of 2-dimensional registers (tiles) representing sub-arrays from a larger 2-dimensional memory image, and accelerators able to operate on tiles. Capability of Intel AMX implementation is enumerated by palettes. Two palettes are supported: palette 0 represents the initialized state and