search for: throws

...index 531ff00..ed491b1 100644 --- a/libswfdec/swfdec_as_context.c +++ b/libswfdec/swfdec_as_context.c @@ -673,6 +673,52 @@ swfdec_as_context_get_frame (SwfdecAsContext *context) } /** + * swfdec_as_context_throw: + * @context: a #SwfdecAsContext + * @value: a #SwfdecAsValue to be thrown + * + * Throws a new exception in the @context using the given @value. This function + * can only be called if the @context is not already throwing an exception. + **/ +void +swfdec_as_context_throw (SwfdecAsContext *context, const SwfdecAsValue *value) +{ + g_return_if_fail (SWFDEC_IS_AS_CONTEXT (context)); +...

IE6 and IE7 are not correctly handling the ''throw'' command for functions attached to Element via Element.addMethods. Firefox and Safari are fine. See the example below. For IE6: functions called with no attributes (ie: funcName()) correctly handle thrown errors. Funcions called with attributes (ie: funcName("foo")) will respond to the throw command and pass execution

...a you can throw and exception inside a destructor and it does not lead >> to program termination. > > Interesting. I assume that the personality still sees these as just cleanups, > so this must be implemented by running the destructor in a handler which > aborts both unwinds and throws the Program_Error? Right. The dwarf exception library doesn't mind if you throw a new exception inside a cleanup, it just unwinds it. ["Cleanups don't throw" is a C++ specific concept that is built on top of the basic unwinder facilities; gcc does it by wrapping cleanup code in...

On Fri, Jul 15, 2016 at 12:21 PM, Sanjoy Das <sanjoy at playingwithpointers.com > wrote: > Hi Daniel, > > Daniel Berlin wrote: > > As a starting point, LLVM will conservatively not speculate such > > loads and stores; and will leave open the potential to upstream > > logic that will have a more precise sense of when these loads > and

Duncan Sands wrote: > Hi Nicolas, > > >> In order to have exceptions for non-call instructions (such as sdiv, >> load or stores), I'm modifying codegen so that it generates a BeginLabel >> and an EndLabel between the "may throwing" instruction. This is what the >> codegen of an InvokeInst does. >> > > the rule is that all

...as unreachable. As a consequence of that, the call to _Unwind_SjLj_Resume() is optimized away, and thus the function is considered to not throw in PruneEH.cpp. Very strange stuff. Thoughts on how to proceed in figuring out the root cause of what's going wrong? bool ShouldThrow; int throws() try { if (ShouldThrow) throw 7; return 123; } catch (...) { printf("'throws' threw an exception: rethrowing!\n"); throw; }

...f a particular frame never had an exception handler and could've been skipped safely. However, this scheme allows you to easily switch to one of two other implementations based on profiling data on a per-callsite basis: 1. high exception volume -- if an invoke has seen too many exception throws, recompile by replacing the invoke with a call followed by a test of "pending exception" and branch. The logic to generate the branch target should largely be the same as logic to generate the landing pad block. 2. low exception volume -- keep the invoke, but put a deoptimi...

...ent anyway. > In Ada you can throw and exception inside a destructor and it does not lead > to program termination. Interesting. I assume that the personality still sees these as just cleanups, so this must be implemented by running the destructor in a handler which aborts both unwinds and throws the Program_Error? John.

Hi Nicolas, > In order to have exceptions for non-call instructions (such as sdiv, > load or stores), I'm modifying codegen so that it generates a BeginLabel > and an EndLabel between the "may throwing" instruction. This is what the > codegen of an InvokeInst does. the rule is that all instructions between eh begin labelN and eh end labelN must unwind to the same

On 01/05/2017 03:10 PM, Reid Kleckner wrote: > On Thu, Jan 5, 2017 at 10:39 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > I don't understand why that's desirable, and I think it would > severely limit our ability to infer these attributes for functions > that unwind. You'd need to prove things -- likely

...the case of your example it seems that llvm-gcc didn't optimize the > code as well as it might, since the invoke is redundant. > But there are cases when the outcomes will be different. In case of gcc frontend terminate() will be called when the original exception's destructor throws an exception and in case of clang Unwind_Resume_or_Rethrow will be called which is different. I think one of these cases must be an incorrect behavior. Yuri

libswfdec/swfdec_as_context.c | 11 + libswfdec/swfdec_as_context.h | 2 libswfdec/swfdec_as_interpret.c | 228 +++++++++++++++++++++++++++++++++++++++- 3 files changed, 238 insertions(+), 3 deletions(-) New commits: commit a599de99164b86347df25cd615d6287487878c3e Author: Pekka Lampila <pekka.lampila at iki.fi> Date: Sat Oct 27 00:26:04 2007 +0300 Add some comments to Try

...hat, the call to _Unwind_SjLj_Resume() is optimized > away, and thus the function is considered to not throw in PruneEH.cpp. > Very strange stuff. > > Thoughts on how to proceed in figuring out the root cause of what's > going wrong? > > > bool ShouldThrow; > > int throws() > try > { > if (ShouldThrow) throw 7; return 123; > } catch (...) { > printf("'throws' threw an exception: rethrowing!\n"); > throw; > } > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.ui...

...xception inside a destructor and it does not lead >>> to program termination. >> >> Interesting. I assume that the personality still sees these as just cleanups, >> so this must be implemented by running the destructor in a handler which >> aborts both unwinds and throws the Program_Error? > > Right. The dwarf exception library doesn't mind if you throw a new exception > inside a cleanup, it just unwinds it. ["Cleanups don't throw" is a C++ specific > concept that is built on top of the basic unwinder facilities; gcc does it by >...

Hello, For code: try { throw 42; } catch(int e){} Are there any helpers in LLVM API to give me info that in "try block" there is a throw which will be executed? I am interested in info "yes, this block throws". Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180516/6f938b93/attachment.html>

Bill, I believe the empty-exception-specification example is a red- herring, but that if you can construct an example where you think a landing-pad requires multiple filter lists then I think we can then have a productive conversation about it. I believe we can only get multiple filter lists in a landing-pad if we attempt to merge exception-regions, and since filters are only an

Hi all, I feel that there are two problems with the existing infrastructure: * The nounwind attribute is ambiguous for (1) not throwing exceptions and (2) not performing stack unwinding. I feel that it will be better to separate this in two different attributes * There is some problem when the function has both uwtable and nounwind. Although, I think it fine to keep the current definition of

...tion call that gets inlined also will have an implied conditional goto for any function it calls, now to two possible landing pads. Is it safe to move code across this goto? It's comparatively hard to prove things about that. >> >> Worse, a compiler generally know if a function call throws or not, or event the type of exception that will get thrown. It definitely knows what the return type and value of a function is. >> >> It is very easy for a compiler to reason about the error checking around a function call--the code is all there and explicit. All of this restricts wha...

I'd love to hear more details. Are you saying that this infinite loop is a limitation of EHABI table format, and not something that can be fixed in the compiler? Meanwhile, please notice that gcc behavior matches current clang behavior that I described above. We would not want to create an incompatibility. On Fri, Feb 14, 2014 at 8:42 PM, Logan Chien <tzuhsiang.chien at gmail.com>

Hi Piotr, On March 31, 2017 at 1:07:12 PM, Piotr Padlewski (piotr.padlewski at gmail.com) wrote: > [snip] > Do I understand it correctly, that it is legal to do the hoist because all > of the instructions above %vtable does not throw? Yes, I think you're right.  HeaderMayThrow is a conservative approximation, and the conservativeness is biting us here. > Are there any plans to