search for: __finally

...filters). In particular, when an outer filter is invoked before entering an inner finally, which piece of IR reflects the filter's side-effects? To take a concrete example, consider this C code: void foo() { int x; __try { x = 0; __try { x = 2; may_throw(); } __finally { if (x == 1) { printf("correct\n"); } else { printf("incorrect\n"); } } } __except (x = 1) { } } The IR for the path from "x = 2" to the load of x in the __finally (via the exception edge) looks like so: store i...

(Moving this discussion on list as this could be of general interest.) My current work-in-progress implementation is attempting to map out the blocks used by a landing pad before it starts outlining. It creates a table of catch and cleanup handlers with the block at which each one starts. During outlining I intend to have another mechanism to check to see if we’ve already outlined the handler

...when I suggest that we change the language rules to maintain that invariant. :-) Instead, the EH preparation pass is responsible for establishing that invariant by duplicating blocks, but it should be *way* easier with real basic block terminator instructions to mark handler transitions. > For __finally, we outline the finally body early in clang and emit two > calls to it as before, but passing in the frameaddress as an argument > > But then you have to frameescape any __finally-referenced local before > optimization, and doesn't that defeat the purpose of delaying funclet > ou...

...easonable to hold onto the idea as future work, though. In the meantime, frontends can decide for themselves whether they want code size or stronger optimization of cleanups by doing early outlining or not. The only way we can hit the quadratic growth from clang is if someone is nesting inside SEH __finally blocks, at which point I'm pretty OK letting that get bloated. If we're not going to use the construct in Clang, LLVM passes won't see it as often, and it'll stay buggy longer. The version of this feature that I like so far is probably entercleanup / endcleanup, something along the...

I’m not sure I understand what you are suggesting in terms of how this should be handled. I agree that the cleanup code is unlikely to be complex, but obviously we still need some way to handle any cases that unlikely but possible. I hadn’t even thought about what might be in a __finally block. I was thinking about destructors being inlined. Obviously that puts a practical limit on what will be there, but not really a theoretical limit. So I’m looking for an implementation that will handle the typical cases efficiently but still not break if the very rare case turns up. It occu...

I was wondering if the upcoming LLVM 3.5 release will have support for Microsoft Windows Structured Exception handling (e.g., __try/__except/__finally)? Thanks, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140730/e3d18989/attachment.html>

...erence to the catchblock itself, because tail merging could kick in like you mention. Undoing this would be and currently is the job of WinEHPrepare. I guess I felt like the extra representational complexity wasn't worth the confidence that it would buy us. > - What is the plan for cleanup/__finally code that may be executed on > either normal paths or EH paths? One could imagine a number of options > here: > > + require the IR producer to duplicate code for EH vs non-EH paths > > + duplicate code for EH vs non-EH paths during EH preparation > > + use resume to exit th...

On Sat, May 16, 2015 at 7:29 AM, Steve Cheng <steve.ckp at gmail.com> wrote: > On 2015-05-15 18:37:58 -0400, Reid Kleckner said: > > After a long tale of sorrow and woe, my colleagues and I stand here >> before you defeated. The Itanium EH representation is not amenable to >> implementing MSVC-compatible exceptions. We need a new representation that >> preserves

...microsoft.com> wrote: > > teach the inliner how to undo framerecover and let the optimization > fall out that way > > You'd still have the problem that the referenced variables were > frameescaped and appear to be read/written at unrelated calls. > > > > > __finally is pretty rare > > `__finally` may be rare in SEH code, but `finally` is quite common in .Net > code, so we're going to need a solution that avoids early `finally` > outlining for the same reasons we're avoiding early `catch` outlining. > > While we do need something that&...

...hardware exceptions (/EHa) is critical functionality, but it's not clear to me if local unwind is truly worth implementing. Having looked at the code briefly, it seemed like a large portion of the complexity comes from local unwind. Today, clang crashes on this small example that jumps out of a __finally block, but the intention was to reject the code and avoid implementing the functionality. Clang does, in fact, emit a warning: $ clang -c t.cpp t.cpp:7:7: warning: jump out of __finally block has undefined behavior [-Wjump-seh-finally] goto lu1; ^ Local unwind, in my view, is the user s...

...ws SEH for the COFF format. That is, implementing synchronous exceptions using the native platform's asynchronous exception framework. I am concerned with representing the handling of asynchronous exceptions in LLVM as there is language-level support in Windows C++ compilers via __try/__except/__finally blocks (Clang already supports this at the AST level). I believe that this is not currently possible and needs new no-op instructions or a change in syntax. A SEH-block in C++ consists of a __try block and either of two following blocks: * A __except block consisting of a filter and body * A __f...

...nsics. Also, we should emit the tables for each function, which is not a simple task either. For 64-bit SEH, things are simpler. There are no more instructions to emit than no-SEH code. We have only two tasks: emit the table for each function, and place some code right. If I remember it correctly, __finally block code should be replicated at 2 places: one in the original function as part of the normal execution path, and other one separately if anything in __try block goes south. As for the table part, I've seen some commits from Kai(as CC'ed in this email) doing it, you should ask him for det...

...hardware exceptions (/EHa) is critical functionality, but it's not clear to me if local unwind is truly worth implementing. Having looked at the code briefly, it seemed like a large portion of the complexity comes from local unwind. Today, clang crashes on this small example that jumps out of a __finally block, but the intention was to reject the code and avoid implementing the functionality. Clang does, in fact, emit a warning: $ clang -c t.cpp t.cpp:7:7: warning: jump out of __finally block has undefined behavior [-Wjump-seh-finally] goto lu1; ^ Local unwind, in my view, is the user s...

...t for __try and __except in clang. It looks like this is mostly implemented by your changes in the D5607 review, but there hasn't been any activity on that review for quite a while. You're going to rewrite a lot of that to change the way filters are implemented, right? * Add support for __finally in clang I haven't seen anything for this yet. Based on various discussions, it seems like you intend to mix C++ scope cleanup with SEH handlers in ways that MSVC specifically punts. Is that right? * Add support for unwinding in frames with no exception handlers I'm not clear as to wh...

Hi, This page http://clang.llvm.org/docs/MSVCCompatibility.html says clang-cl supports C ++ exceptions, but I cannot compile code with simple try{}catch{} error : cannot compile this throw expression yet What am i doing wrong? -- WBR, Arkady Shapkin aka Dragon -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, all, The intend of this thread is to complete the support for Windows SEH. Currently there are two major missing features: Jumping out of a _finally and Hardware exception handling. The document below is my proposed design and implementation to fully support SEH on LLVM. I have completely implemented this design on a branch in repo:

...hat is, implementing > synchronous exceptions using the native platform's asynchronous > exception framework. > > I am concerned with representing the handling of asynchronous > exceptions in LLVM as there is language-level support in Windows C++ > compilers via __try/__except/__finally blocks (Clang already supports > this at the AST level). I believe that this is not currently possible > and needs new no-op instructions or a change in syntax. > > A SEH-block in C++ consists of a __try block and either of two > following blocks: > > * A __except block consist...

...hardware exceptions (/EHa) is critical functionality, but it's not clear to me if local unwind is truly worth implementing. Having looked at the code briefly, it seemed like a large portion of the complexity comes from local unwind. Today, clang crashes on this small example that jumps out of a __finally block, but the intention was to reject the code and avoid implementing the functionality. Clang does, in fact, emit a warning: $ clang -c t.cpp t.cpp:7:7: warning: jump out of __finally block has undefined behavior [-Wjump-seh-finally] goto lu1; ^ Local unwind, in my view, is the user s...

...LLVM IR. > > Briefly, this is how I think we should represent it: > 1. Use a different landingpad personality function for SEH > (__C_specific_handler / _except_handlerN) > 2. Use filter function pointers in place of type_info globals > 3. Outline cleanups such as destructors and __finally on Windows, and > provide a function pointer to the landingpad cleanup clause > > See the example IR at the end of this email. Read on if you want to > understand why I think this is the right representation. > > --- > > Currently LLVM's exception representation is desig...

...ion, which is not a simple >> task either. >> >> For 64-bit SEH, things are simpler. There are no more instructions to >> emit than no-SEH code. We have only two tasks: emit the table for each >> function, and place some code right. If I remember it correctly, >> __finally block code should be replicated at 2 places: one in the >> original function as part of the normal execution path, and other one >> separately if anything in __try block goes south. >> As for the table part, I've seen some commits from Kai(as CC'ed in this >> email)...