Displaying 5 results from an estimated 5 matches for "__z3barv".
Did you mean:
_z3barv
2011 Jul 28
0
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
...n maps.
What compiler are you talking about, and on what platform?
The results I'm seeing clearly have both gcc and clang on Darwin generating
different LSDAs for your cleanup examples and your catch-all examples.
Here is the 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_t...
2011 Jul 28
2
[LLVMdev] LLVMdev Digest, Vol 85, Issue 50
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.
2011 Aug 05
0
[LLVMdev] RFC: Exception Handling Rewrite
...0
So the call to "foo" 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 tab...
2011 Aug 05
3
[LLVMdev] RFC: Exception Handling Rewrite
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
2009 Sep 25
2
[LLVMdev] MinGW/MSVC++ uses different ABI for sret
...ct 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@@YA?AUS@@XZ ; foo
EXTRN ?bar@@YA?AUS@@XZ:PROC ; bar
; Function compile flags: /Ogtpy
; COMDAT ?foo@@YA?AUS@@XZ
_TEXT SEGMENT
$T2548 = -16...