search for: __ztipkc

...g L$set$6 # length .set L$set$7,L20-LFB9 .long L$set$7 # landing pad .byte 0x5 # uleb128 0x5; action . . . [ elided for readability ] .byte 0x7d # Action record table .byte 0x0 .byte 0x2 .byte 0x7d .byte 0x7f .byte 0x7d .byte 0x0 .byte 0x79 .align 2 .long __ZTI1B+4 at GOTPCREL .long __ZTIPKc+4 at GOTPCREL .long __ZTI1A+4 at GOTPCREL .byte 0x1 # Exception specification table .byte 0x0 .byte 0x3 .byte 0x0 As you can see, foo() has been completely inlined into bar(). The entry for the call to "baz" (from the foo() function) is shown here in the EH table. The action associ...

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

...et L$set$7,LEHE2-LEHB2 .long L$set$7 # length .set L$set$8,L24-LFB4 .long L$set$8 # landing pad .byte 0x7 # uleb128 0x7; action . . . .byte 0x1 # Action record table .byte 0x0 .byte 0x2 .byte 0x7d .byte 0x3 .byte 0x7d .byte 0x0 .byte 0x7d .align 2 .long __ZTIi+4 at GOTPCREL .long __ZTIPKc+4 at GOTPCREL .long 0 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...

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