search for: __zn1ad1ev

...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 cmpq $3, %rdx je L9 # basic block 20 cmpq $2, %rdx jne L30 # basic block 21 jmp L39 . . . L39: # The catch handler . . . GCC_except_table0: LLSDA4: . . . .set L$set$6,LEHB2-LFB4 .long L$set$6 # region 2 start .set L$set$7,LEHE2-LEHB...

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

...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 "action" variable. > > So the information is needed at the invoke site. > > The informat...