similar to: [LLVMdev] invoke/unwind

If it helps, to see what is involved, outside of a pure IR context, see the example code, and doc at: http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism#Source_Code:_exceptionDemo.cpp Although this is a pure example that shows several test cases, including foreign exception interaction, it is not an IR example, but rather a LLVM IR API example. It would be interesting to see a pure

On 01/13/2010 04:08 AM, Garrison Venn wrote: > If it helps, to see what is involved, outside of a pure IR context, > see the example code, and doc at: > > http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism#Source_Code:_exceptionDemo.cpp It does, although in the "let me show you why this is too much to tackle" way. > Although this is a pure example that

On Jan 13, 2010, at 12:46, Dustin Laurence wrote: > On 01/13/2010 04:08 AM, Garrison Venn wrote: > >> If it helps, to see what is involved, outside of a pure IR context, >> see the example code, and doc at: >> >> http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism#Source_Code:_exceptionDemo.cpp > > It does, although in the "let me show you

Hi Dustin, the code generators do not support unwind, only the interpreter does. Ciao, Duncan.

On 01/13/2010 02:07 AM, Duncan Sands wrote: > Hi Dustin, the code generators do not support unwind, only the > interpreter does. Ah, the secret is not to even try to frob the gnorts. Manual unwinding, here I come. :-( I was going to say the interpreter doesn't either, but then I recalled it JITs when it can. I don't know how to call into libc from the interpreter to test that.

Here is a small doc patch based on answers from the list and from the links mentioned. For stylistic consistency I've followed the language in the va_arg description for the analogous situation. Dustin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: LangRef.unwind.patch URL:

Hi Dustin, > Here is a small doc patch based on answers from the list and from the > links mentioned. For stylistic consistency I've followed the language > in the va_arg description for the analogous situation. as I mentioned in another email, unwind is not completely unsupported: it does work for rethrowing an exception. Ciao, Duncan.

On 30/09/16 20:10, Reid Kleckner wrote: > On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be > <mailto:jonas-devlists at watlock.be>> wrote: > > So, can I use invoke and landingpad without using any of the other > exception handling intrinsics? (in combination with a dummy personality > function) Or will LLVM in all cases insist on

On 01/13/2010 01:52 PM, Duncan Sands wrote: > as I mentioned in another email, unwind is not completely unsupported: > it does work for rethrowing an exception. Good point. Not understanding how languages implement exceptions under the hood, I lose the nuances that should be in a reference document. How's this version? Dustin -------------- next part -------------- An embedded and

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

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

On Wed, Jan 13, 2010 at 4:07 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Dustin, the code generators do not support unwind, only the > interpreter does. > > Ciao, > > Duncan. > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu >

On Mon, Jun 15, 2009 at 7:08 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: >> The documentation of unwind/invoke is quite clear and does exactly >> what I need: unwinding the stack. I don't need it to carry an object >> back. I don't need it to figure out what the type of the object is or >> what catch() blocks it matches. I just need it to unwind

> The documentation of unwind/invoke is quite clear and does exactly > what I need: unwinding the stack. I don't need it to carry an object > back. I don't need it to figure out what the type of the object is or > what catch() blocks it matches. I just need it to unwind the stack. > The rest is my job as a part of the runtime. Unfortunately, I have > learned that while

The documentation of unwind/invoke is quite clear and does exactly what I need: unwinding the stack. I don't need it to carry an object back. I don't need it to figure out what the type of the object is or what catch() blocks it matches. I just need it to unwind the stack. The rest is my job as a part of the runtime. Unfortunately, I have learned that while this works with the bytecode

I am trying to employ the ABCD optimization pass to remove unnecessary branches in the code my compiler generates. But in its current form (yesterday's trunk) the pass changes the behavior of the code such that execution yields invalid results, which is obviously not what I want. The switch in the following listing is used to implement a virtual method call, 99999 and 100000 are type

Hi Wesley, > The documentation of unwind/invoke is quite clear and does exactly > what I need: unwinding the stack. I don't need it to carry an object > back. I don't need it to figure out what the type of the object is or > what catch() blocks it matches. I just need it to unwind the stack. > The rest is my job as a part of the runtime. Unfortunately, I have > learned

On 2009-06-15 20:26, Wesley W. Terpstra wrote: > On Mon, Jun 15, 2009 at 7:08 PM, Aaron > Gray<aaronngray.lists at googlemail.com> wrote: > >>> The documentation of unwind/invoke is quite clear and does exactly >>> what I need: unwinding the stack. I don't need it to carry an object >>> back. I don't need it to figure out what the type of the

Hi - rsync newbie here. I have a situation where I have multiple instances of CMS website code living in the same root directory and having parallel dir structures, so something like this: /my_code/root_dir/instance_1 /my_code/root_dir/instance_2 /my_code/root_dir/instance_3 each instance_n has the same directory structure and owns the same files for the most part with small isolated customer

Folks, As of this run: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/746 There are three classes of failures that need fixing before we get the bot green: 1. AddressSanitizer.BuiltinLongJmpTest Unit Test Two configurations fail: * Asan-arm-inline-Test * Asan-arm-with-calls-Test I wonder what's the best way to run it individually and reduce the error. I'm not