search for: throwness

doc/swfdec-sections.txt | 2 libswfdec/swfdec_as_context.c | 54 ++++++++++++++++++- libswfdec/swfdec_as_context.h | 9 ++- libswfdec/swfdec_as_interpret.c | 79 ++++++++++++++-------------- test/trace/Makefile.am | 7 ++ test/trace/try-throw-in-finally-6.swf |binary

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

Hi John, >> I'm pointing out that if the invoke instruction >> is removed and catch information is attached to entire basic blocks, then if no >> care is taken then it is perfectly possible to use %x before it is defined as >> explained in my previous email, blowing up the entire LLVM system. Clearly the >> solution is to not allow this by not allowing values

...unsafe to hoist a load before a function call which may throw, the throw might prevent a pointer dereference. Likewise, it is unsafe to sink a store after a call which may throw. The caller might be able to observe the difference." This then leads to the problem i mentioned - because the may-throwness is not expressed at the bb level (or in the CFG, by having the call end the block, or at the least, a fake abnormal CFG edge), everything has to go checking every instruction along the entire path they want to hoist, whereas hoisting is normally just a simple dataflow problem with BB level properti...

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

All, The following relatively simple function is behaving oddly under SJLJ exception handling. Specifically, it's being diagnosed by the optimizer as being a nounwind function, which is obviously incorrect. From what I can tell so far, something is going wrong analyzing the call to __cxa_end_catch() invoke arm_apcscc void @__cxa_end_catch() to label %Unwind unwind label

Hi Kevin, To elaborate on Philip's point, depending on the state Pyston's runtime already is in, you may have the choice of using a hybrid of a "pending exception" word in your runtime thread structure, and an implicit alternate ("exceptional") return address for calls into functions that may throw. This lets you elide the check on the pending exception word after

On Nov 25, 2010, at 3:03 AM, Duncan Sands wrote: > I'm pointing out that if the invoke instruction > is removed and catch information is attached to entire basic blocks, then if no > care is taken then it is perfectly possible to use %x before it is defined as > explained in my previous email, blowing up the entire LLVM system. Clearly the > solution is to not allow this by not

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

On 07/12/2010 00:23, Duncan Sands wrote: > IIRC, __cxa_end_catch may throw an exception because it runs the destructor > for the exception object, which can execute arbitrary user code and thus may > throw an exception. This is why it is sometimes correct to use invoke for it. > However in the case of your example it seems that llvm-gcc didn't optimize the > code as well as it

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

It would help if you post the -O0 and -O1bitcode files. Does it reproduce with opt -O1? If so, use -debug-pass= to figure out when things started going wrong. Does it make sense to compare the bitcode against code generated for x86 target? Evan On Aug 16, 2009, at 11:46 AM, Jim Grosbach wrote: > All, > > The following relatively simple function is behaving oddly under SJLJ >

On Nov 28, 2010, at 9:50 AM, Duncan Sands wrote: >>> 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

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:

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

On Thu, Aug 13, 2020 at 4:38 PM Haoran Xu <haoranxu510 at gmail.com> wrote: > > Hello David and Sterling, thanks for the reply! > > I have no intention to heat up the discussion, please pardon me if I asked questions that might sound silly to you -- it's just that I truly didn't understand since I'm not expert in llvm or optimizer or exception handling at all. >

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