search for: eh_state

...t stack that aren’t in the current landing pad’s action table a. If a catch is popped that had been assumed to have the same state as a catch that isn’t being popped its state number and all state numbers above it need to be incremented b. When a catch is popped, the next available eh_state is assigned to its handler 4. As an action is pushed to the current stack, it is assigned an eh_state in the master list a. If the action was an unwind or if it was a cacth after an unwind, the next available eh_state is incremented b. If the action was a catch following a catch that was also...

Nice. This seems like a good starting design for some patches. I'm not sure exactly how step 3.a works. Does it stem from step 4.b which assigns the same eh_state to two catch handlers? It seems like these rules would come into play in these examples: // 'catch int' and 'catch float' have the same incoming eh_state range try { f(); } catch (int) { g(); } catch (float) { h(); } // 'catch float' covers more than 'catch int', h...

...n the handling of that case a bit more in terms of the .xdata tables that will eventually need to be generated, and maybe then we can converge on a reasonable solution. First, we need to assign EH states to all of the code. Ideally that would end up looking something like this: void test() { // eh_state = -1 try { // eh_state = 0 Outer outer; // eh_state = 1 try { // eh_state = 2 Inner inner; // eh_state = 3 do_inner_thing(); // eh_state = 2 (because we’re going to destruct inner here) } catch (int) { // eh_state = 4 handle_int();...

...t; pad’s action table > > a. If a catch is popped that had been assumed to have the same state as > a catch that isn’t being popped > > its state number and all state numbers above it need to be > incremented > > b. When a catch is popped, the next available eh_state is assigned to > its handler > > 4. As an action is pushed to the current stack, it is assigned an eh_state > in the master list > > a. If the action was an unwind or if it was a cacth after an unwind, > the next available eh_state is incremented > > b. If the actio...

I am working on adding support for C++ exception handling when compiling for a native Windows target (that is a target with "MSVC" specified as the environment). Because of differences between how the native Windows runtime handles exceptions and the Itanium-based model used by current LLVM exception handling code, I believe this will require some extensions to the LLVM IR, though

Thanks, Reid. These are good points. So I guess that does take us back to something more like my original proposal. I like your suggestion of having some kind of “eh.actions” intrinsic to represent the outlining rather than the extension to landingpad that I had proposed. I was just working on something like that in conjunction with my second alternative idea. What I’d really like is to have

...t stack that aren’t in the current landing pad’s action table a. If a catch is popped that had been assumed to have the same state as a catch that isn’t being popped its state number and all state numbers above it need to be incremented b. When a catch is popped, the next available eh_state is assigned to its handler 4. As an action is pushed to the current stack, it is assigned an eh_state in the master list a. If the action was an unwind or if it was a cacth after an unwind, the next available eh_state is incremented b. If the action was a catch following a catch that was also...