search for: rethrow

...t; >> I've read the docs on LLVM exceptions, but I don't see any examples. A little help? > > I don't think this has anything to do with LLVM's IR-level exception system. It sounds to me like you just need a way to handle C++ exceptions inside of the C++ code and then rethrow so that the JIT's caller can do its thing. (Right?) Right. The call sequence is: my_lib(1) -> JIT_code -> C_thunk -> my_lib(2) The JIT code creates Functions that create C++ objects on their stacks (by using alloca instructions then calling a C thunk that calls the C++ object'...

...t; > Thanks to a previous answer, I now have everything working. My next problem is to deal with exceptions that may be thrown from the C++ functions that are called via the thunks, e.g., what if that->next() throws an exception? I need to be able to catch it, call a clean-up function, and rethrow the exception so the code calling the JIT'd code can deal with the exception. > > I've read the docs on LLVM exceptions, but I don't see any examples. A little help? > I don't think this has anything to do with LLVM's IR-level exception system. It sounds to me like y...

...> } Thanks to a previous answer, I now have everything working. My next problem is to deal with exceptions that may be thrown from the C++ functions that are called via the thunks, e.g., what if that->next() throws an exception? I need to be able to catch it, call a clean-up function, and rethrow the exception so the code calling the JIT'd code can deal with the exception. I've read the docs on LLVM exceptions, but I don't see any examples. A little help? One thought might be to try to handle all the C++ exception code in the thunks. The JIT'd code would create/maintain...

I am the author of the *tryCatchLog* package and want to - suppress selected conditions (warnings and messages) - rethrow selected conditions (e.g a specific warning as a message or to "rename" the condition text). I could not find any reliable unique identifier for each possible condition - that (base) R throws - that 3rd-party packages can throw (out of scope here). Is there any reliable way to ident...

On Sun, 16 Apr 2023 at 12:58, nospam at altfeld-im.de <nospam at altfeld-im.de> wrote: > > I am the author of the *tryCatchLog* package and want to > > - suppress selected conditions (warnings and messages) > - rethrow selected conditions (e.g a specific warning as a message or to "rename" the condition text). > > I could not find any reliable unique identifier for each possible condition > > - that (base) R throws > - that 3rd-party packages can throw (out of scope here). > > Is t...

...> I've read the docs on LLVM exceptions, but I don't see any examples. A little help? >> >> I don't think this has anything to do with LLVM's IR-level exception system. It sounds to me like you just need a way to handle C++ exceptions inside of the C++ code and then rethrow so that the JIT's caller can do its thing. (Right?) > > Right. The call sequence is: > > my_lib(1) -> JIT_code -> C_thunk -> my_lib(2) > > The JIT code creates Functions that create C++ objects on their stacks (by using alloca instructions then calling a C thunk...

...and an exception is thrown during the use of x & y, then control flow will never reach my JIT'd code that calls the destructors manually. I've tested this. It behaves as I describe it. So, to ensure the destructors are called, I have to catch the exception, call the destructors, and rethrow. I can't see any other way despite what you've been saying. If I'm still wrong, I'd really appreciate your continued patience in explaining where. - Paul

On Apr 8, 2012, at 10:40 PM, Bill Wendling wrote: > What gets returned by the landingpad instruction (%0 here) is normally a structure. LLVM doesn't typically treat aggregates as first-class citizens. In particular, you shouldn't store the whole structure to memory like you do to %5. You can use 'extractvalue' to get the different elements of the structure. If you need to

On Mar 23, 2012, at 4:46 PM, Bill Wendling wrote: > You need to look at how the equivalent code in C++ looks in LLVM IR. The "do something with x & y" part will be an 'invoke' that lands on at landing pad, where you will then call the d'tor to your allocated object. OK, after a lot of tinkering (and looking at the ExceptionDemo.cpp file), I have something that works

On Mar 23, 2012, at 6:27 AM, Paul J. Lucas wrote: > On Mar 22, 2012, at 5:29 PM, Bill Wendling wrote: > >> On Mar 22, 2012, at 11:40 AM, Paul J. Lucas <paul at lucasmail.org> wrote: >> >>> Unfortunately, I'm not following. How is having the code that catches all exceptions in a separate function different from what I proposed (putting the try/catch in the

On Mar 22, 2012, at 5:29 PM, Bill Wendling wrote: > On Mar 22, 2012, at 11:40 AM, Paul J. Lucas <paul at lucasmail.org> wrote: > >> Unfortunately, I'm not following. How is having the code that catches all exceptions in a separate function different from what I proposed (putting the try/catch in the thunks)? (Ideally, I want to minimize layers of function calls.) Again

...ception is thrown during the use of x & y, then control flow will never reach my JIT'd code that calls the destructors manually. I've tested this. It behaves as I describe it. > > So, to ensure the destructors are called, I have to catch the exception, call the destructors, and rethrow. I can't see any other way despite what you've been saying. If I'm still wrong, I'd really appreciate your continued patience in explaining where. > You need to look at how the equivalent code in C++ looks in LLVM IR. The "do something with x & y" part will be an...

On Apr 11, 2012, at 8:41 AM, Paul J. Lucas wrote: > On Apr 8, 2012, at 10:40 PM, Bill Wendling wrote: > >> On Apr 8, 2012, at 8:47 AM, Paul J. Lucas wrote: >> >>> But I assume [the personality function] works only for a *nix/g++ system. My code also needs to work when compiled on Windows using Visual Studio and I'm guessing that it needs a different personality

On Sun, 2023-04-16 at 13:52 +0200, I?aki Ucar wrote: > I agree that something like this would be a nice addition. With the > current condition system, it would be certainly easy (but quite a lot > of work) to define a hierarchy of built-in conditions, and then use > them consistently throughout base R. Yes, a typed condition system would be great. I have two other ideas: By

On Apr 8, 2012, at 10:40 PM, Bill Wendling wrote: > On Apr 8, 2012, at 8:47 AM, Paul J. Lucas wrote: > >> But I assume [the personality function] works only for a *nix/g++ system. My code also needs to work when compiled on Windows using Visual Studio and I'm guessing that it needs a different personality function. Where do I get that? > > That's not something

...ype_case 2. The exceptions were from the ActiveRecord namespace 3. Including Validations hooked on methods like save It would seem to me that Validations would be best off as an independent mixin. All ActiveRecord would need to do is mix it, add validates_numericay (1), catch the exceptions and rethrow them as ActiveRecord exceptions (2), and hook save type methods (3). What does everyone say? Would this be a good change? Is there an important reason for *not* doing this? -- Posted via http://www.ruby-forum.com/.

On Apr 8, 2012, at 4:20 AM, Bill Wendling wrote: > On Apr 4, 2012, at 9:32 PM, Paul J. Lucas wrote: > >> This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are called) and the exception is propagated back up the C++ code that called the

...; compiler SEH personality (_C_specific_handler) doesn't have that, right? If > you could manage __try, __finally already, doesn't that provide the > solution? > Right, __CxxFrameHandler3 is a lot more constraining than __C_specific_handler. The SEH personality doesn't let you rethrow exceptions, so once you catch the exception you're done, you're in the parent function. My understanding is that C++ works by having an active catch handler on the stack. > Let me be precise. Let's take your example with the "ambiguous IR > lowering": I snipped the e...

On Apr 4, 2012, at 9:32 PM, Paul J. Lucas wrote: > On Mar 23, 2012, at 4:46 PM, Bill Wendling wrote: [...] > This all seems to work just fine. I can throw a C++ exception either in a C++ object's constructor or in an ordinary member function and the stack unwinds correctly (the object's destructors are called) and the exception is propagated back up the C++ code that called the

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: