search for: __x86

...==89768== ABORTING My guess is that this is caused by the following code being moved to a branch island: Dump of assembler code for function __cxa_throw: 0x00008f60 <__cxa_throw+0>: push %esi 0x00008f61 <__cxa_throw+1>: push %ebx 0x00008f62 <__cxa_throw+2>: call 0x7a60 <__x86.get_pc_thunk.bx> Perhaps this makes __x86.get_pc_thunk.bx return an incorrect value. Since libstdc++-v3 is built together with gcc, the two issues related to instructions being moved to another place can be solved by padding __cxa_throw() with five NOP instructions (enough to hold a JMP). I be...

...is that this is caused by the following code being moved to a > branch island: > > Dump of assembler code for function __cxa_throw: > 0x00008f60 <__cxa_throw+0>: push %esi > 0x00008f61 <__cxa_throw+1>: push %ebx > 0x00008f62 <__cxa_throw+2>: call 0x7a60 <__x86.get_pc_thunk.bx> > > Perhaps this makes __x86.get_pc_thunk.bx return an incorrect value. > > Since libstdc++-v3 is built together with gcc, the two issues related > to instructions being moved to another place can be solved by padding > __cxa_throw() with five NOP instructions...

...following code being moved to a > > branch island: > > > > Dump of assembler code for function __cxa_throw: > > 0x00008f60 <__cxa_throw+0>: push %esi > > 0x00008f61 <__cxa_throw+1>: push %ebx > > 0x00008f62 <__cxa_throw+2>: call 0x7a60 <__x86.get_pc_thunk.bx> > > > > Perhaps this makes __x86.get_pc_thunk.bx return an incorrect value. > > > > Since libstdc++-v3 is built together with gcc, the two issues related > > to instructions being moved to another place can be solved by padding > > __cxa_throw...

...x86_64 /usr/bin/qemu-system-x86_64 2033 100.000 (no location information) qemu-system-x86_64 /usr/bin/qemu-system-x86_64 [self] ------------------------------------------------------------------------------- 1925 0.2650 (no location information) libdrm_nouveau.so.2.0.0 __x86.get_pc_thunk.si 1925 100.000 (no location information) libdrm_nouveau.so.2.0.0 __x86.get_pc_thunk.si [self] ------------------------------------------------------------------------------- 1765 0.2430 (no location information) nouveau /nouveau 1765 100.000 (...

...following code being moved to a > > branch island: > > > > Dump of assembler code for function __cxa_throw: > > 0x00008f60 <__cxa_throw+0>: push %esi > > 0x00008f61 <__cxa_throw+1>: push %ebx > > 0x00008f62 <__cxa_throw+2>: call 0x7a60 <__x86.get_pc_thunk.bx> > > > > Perhaps this makes __x86.get_pc_thunk.bx return an incorrect value. > > > > Since libstdc++-v3 is built together with gcc, the two issues related > > to instructions being moved to another place can be solved by padding > > __cxa_throw...

...a > > > branch island: > > > > > > Dump of assembler code for function __cxa_throw: > > > 0x00008f60 <__cxa_throw+0>: push %esi > > > 0x00008f61 <__cxa_throw+1>: push %ebx > > > 0x00008f62 <__cxa_throw+2>: call 0x7a60 <__x86.get_pc_thunk.bx> > > > > > > Perhaps this makes __x86.get_pc_thunk.bx return an incorrect value. > > > > > > Since libstdc++-v3 is built together with gcc, the two issues related > > > to instructions being moved to another place can be solved by padd...

...ed to a >> > branch island: >> > >> > Dump of assembler code for function __cxa_throw: >> > 0x00008f60 <__cxa_throw+0>: push %esi >> > 0x00008f61 <__cxa_throw+1>: push %ebx >> > 0x00008f62 <__cxa_throw+2>: call 0x7a60 <__x86.get_pc_thunk.bx> >> > >> > Perhaps this makes __x86.get_pc_thunk.bx return an incorrect value. >> > >> > Since libstdc++-v3 is built together with gcc, the two issues related >> > to instructions being moved to another place can be solved by padding &...

...sland: > > > > > > > > Dump of assembler code for function __cxa_throw: > > > > 0x00008f60 <__cxa_throw+0>: push %esi > > > > 0x00008f61 <__cxa_throw+1>: push %ebx > > > > 0x00008f62 <__cxa_throw+2>: call 0x7a60 <__x86.get_pc_thunk.bx> > > > > > > > > Perhaps this makes __x86.get_pc_thunk.bx return an incorrect value. > > > > > > > > Since libstdc++-v3 is built together with gcc, the two issues related > > > > to instructions being moved to another pl...

On Sun, Jul 14, 2013 at 10:17 AM, Star Tan <tanmx_star at yeah.net> wrote: > Hi Sebastian, > > Yes, you have pointed an important reason. If we comment this source code > you have listed, then the compile-time overhead for oggenc*8.ll can be > reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). > > I just sent another mail to explain why polly-detect pass leads to >

I debugged this a bit and it seems the mach_override patching of __cxa_throw is bogus. The start of that function is patched to jump to garbage. Breakpoint 1, 0x0000000100001c19 in main () (gdb) display/i $pc 2: x/i $pc 0x100001c19 <main+318>: callq 0x100016386 <dyld_stub___cxa_throw> (gdb) si 0x0000000100016386 in dyld_stub___cxa_throw () 2: x/i $pc 0x100016386

Hi Sebastian, Yes, you have pointed an important reason. If we comment this source code you have listed, then the compile-time overhead for oggenc*8.ll can be reduced from 40.5261 ( 51.2%) to 20.3100 ( 35.7%). I just sent another mail to explain why polly-detect pass leads to significant compile-time overhead. Besides the reason you have pointed, another reason is resulted from those string

Jack, can you please upload this test somewhere? On Thu, Nov 29, 2012 at 10:09 AM, Kostya Serebryany <kcc at google.com> wrote: > +glider > The compiler hardly matters here, I would expect the same failures with > clang. > Alex, could you please take a look? > > --kcc > > > On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >