search for: lehb2

..." is marked as being able to throw an "A" type. (The 0x7f in the action record table is a negative 1-based offset into the exception specification table, which itself is a positive 1-based offset into the type table.) Now look at bar: .align 4,0x90 .globl __Z3barv __Z3barv: . . . LEHB2: call __Z3bazv LEHE2: . . . GCC_except_table1: LLSDA9: .byte 0xff # @LPStart format (omit) .byte 0x9b # @TType format (indirect pcrel sdata4) .byte 0x59 # uleb128 0x59; @TType base offset .byte 0x3 # call-site format (udata4) .byte 0x41 # uleb128 0x41; Call-site table length .set L$set$5,...

..._end_cleanup .L7: mov r3, r0 mov r2, r1 cmp r2, #1 beq .L6 bl __cxa_end_cleanup .LEHE1: .L6: mov r0, r3 bl __cxa_begin_catch mov r3, r0 ldr r3, [r3, #0] str r3, [fp, #-8] ldr r0, .L9+4 ldr r1, [fp, #-8] .LEHB2: bl printf .LEHE2: bl __cxa_end_catch mov r3, #0 mov r0, r3 sub sp, fp, #4 ldmfd sp!, {fp, lr} bx lr .L10: .align 2 .L9: .word _ZTIi .word .LC0 .global __gxx_personality_v0 .personality __gxx_personality...

Bill, ooops, yes, I described the meaning of "throw(A)" backwards, but I still think my example shows why you cannot merge LandingpadInst while inlining because multiple filter-lists on a LandingpadInst don't make sense. Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading Duncan's emails, but I read them to mean that your syntax supports

...to the correct catch handler. When you divorce the point where you branch to the catch handler from the point where it throws, you now have a huge gap that cannot be easily recovered from, and may be impossible to recover from. This is the code that G++ generates from the example in my proposal: LEHB2: call __Z3foov LEHE2: . . . L24: # basic block 10 movq %rax, %r12 L5: # basic block 11 movl %edx, %ebx leaq -18(%rbp), %rdi call __ZN1BD1Ev movslq %ebx,%rdx jmp L7 . . . L7: # basic block 15 movl %edx, %ebx leaq -17(%rbp), %rdi call __ZN1AD1Ev movslq %ebx,%rdx jmp L19 . . . L19: # b...

...; call has this: L24: # basic block 4 L3: movl %edx, %ebx movq %rax, %r13 movl $4, %edi call ___cxa_allocate_exception movq %rax, %rdi movl $0, (%rax) movq __ZTIi at GOTPCREL(%rip), %rsi xorl %edx, %edx LEHB2: call ___cxa_throw LEHE2: edx and rax hold the EH selector value and EH object pointer respectively. They get restored before continuing on to the catch in bar (if they get there, which I don't think they will in this case). But that's beside the point. I see what you mean. The...

Hi Bill, > This is similar to my first proposal. yup, I still consider your first proposal to have been basically sound. But it also suffers from a major problem, > which stopped that proposal dead in its tracks. Namely, you have information in > one place which needs to be shared in two different, but possibly disjoint, > places: the type, filters, and personality information. In

On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote: > On Nov 24, 2010, at 6:41 PM, John McCall wrote: >> What you mean is that, given a resume or invoke edge, we need to be able to find the dispatch for the target region. There are ways to make that happen without tagged edges; for example, you could make the landing pad a special subclass of BasicBlock with a pointer to the dispatch,