search for: lehb0

...output I see from gcc-4.2 for your cleanup example: .text .globl __Z3barv __Z3barv: LFB2: pushq %rbp LCFI0: movq %rsp, %rbp LCFI1: pushq %rbx LCFI2: subq $40, %rsp LCFI3: leaq -17(%rbp), %rdi call __ZN3BobC1Ev leaq -18(%rbp), %rdi call __ZN3BobC1Ev leaq -19(%rbp), %rdi call __ZN3BobC1Ev LEHB0: call __Z3foov LEHE0: <snip> .section __TEXT,__gcc_except_tab GCC_except_table0: LLSDA2: .byte 0xff .byte 0xff .byte 0x3 .byte 0x1a .set L$set$0,LEHB0-LFB2 # from .long L$set$0 .set L$set$1,LEHE0-LEHB0 .long L$set$1 .set L$set$2,L6-LFB2 .long L$set$2 .byte 0x0 i.e. the rang...

John, I'm still not sure what you're talking about, I have included the assembly output from two compilations, one with a user explicit catch-all, one with only an implicit cleanup, the DWARF Action Table and Types Table are absolutely identical, as are the indexes used to reference the Action Table from the region maps. -Peter Lawrence.

...w (A) __attribute__((always_inline)); void foo() throw (A) { baz(); } void bar() throw (B) { try { foo(); } catch (const char *s) { printf("%s\n", s); } } GCC outputs this: [Irk:llvm] gcc-4.2 -S -o - -dA t.cpp -O3 .text .align 4,0x90 .globl __Z3foov __Z3foov: . . . LEHB0: call __Z3bazv LEHE0: . . . GCC_except_table0: LLSDA8: .byte 0xff # @LPStart format (omit) .byte 0x9b # @TType format (indirect pcrel sdata4) .byte 0x25 # uleb128 0x25; @TType base offset .byte 0x3 # call-site format (udata4) .byte 0x1a # uleb128 0x1a; Call-site table length .set L$set$0,L...

...fd sp!, {fp, lr} .save {fp, lr} .setfp fp, sp, #4 add fp, sp, #4 .pad #8 sub sp, sp, #8 mov r0, #4 bl __cxa_allocate_exception mov r3, r0 mov r2, #20 str r2, [r3, #0] mov r0, r3 ldr r1, .L9 mov r2, #0 .LEHB0: bl __cxa_throw .LEHE0: .L8: bl __cxa_end_catch .LEHB1: bl __cxa_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...

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