search for: __z3foov

...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 range of instruction...

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.

...oid baz(); void foo() throw (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 tabl...

...%0 = load i32* @b, align 4 ; <i32> [#uses=1] 12. ret i32 %0 13. } 14. 15. declare void @llvm.memory.barrier(i1, i1, i1, i1, i1) nounwind compiled with: 1. llc -mcpu=core2 -mattr=+sse2,+sse3 -f -o test.s test.bc becomes 1. .text 2. .align 4,0x90 3. .globl __Z3foov 4. __Z3foov: 5. movl L_a$non_lazy_ptr, %eax 6. movl $1, (%eax) 7. nop 8. movl L_b$non_lazy_ptr, %eax 9. movl (%eax), %eax 10. ret 11. 12. .section __IMPORT,__pointers,non_lazy_symbol_pointers 13. L_a$non_lazy_ptr: 14. .indirect_symbol _a 15. .long 0 16. L_b$non_lazy_ptr: 17. .indirect_s...

...ct 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: # basic block 19 c...

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

Let's go directly to the example struct S { double dummy1; double dummy2; }; S bar(); S foo() { return bar(); } This is the result of g++ -c -S -O2 (focus on the final `ret'): __Z3foov: LFB0: pushl %ebp LCFI0: movl %esp, %ebp LCFI1: pushl %ebx LCFI2: subl $20, %esp LCFI3: movl 8(%ebp), %ebx movl %ebx, (%esp) call __Z3barv pushl %eax movl %ebx, %eax movl -4(%ebp), %ebx leave ret $4 This is the result of cl -O2 -c -Fa (again, focus on the final `ret') PUBLIC ?foo...

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

...thing essential or you are. To clear this up, I suggest you send me evil examples and I will show you how my scheme handles them (or doesn't handle them, if I am indeed failing to see something). > This is the code that G++ generates from the example in my proposal: ... > If the call to __Z3foov throws, we need to set up the tables to that it knows > that it needs to call the __ZN1BD1Ev and __ZN1AD1Ev cleanups. This information > requires looking at the invoke instruction – i.e., "where should I land?". It > also needs to know which types it can catch in order to get the...