search for: __vtt_parm

Displaying 2 results from an estimated 2 matches for "__vtt_parm".

2012 Dec 04
0
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
...win_objdir/gcc/testsuite/g++/covariant3.exe Reading symbols for shared libraries +++++................................. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x000010002000068a 0x00000001000015d0 in c1::c1 (this=0x100003d08, __vtt_parm=0x100003450) at /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121204/gcc/testsuite/g++.dg/abi/covariant3.C:10 10 struct c1 : virtual c0 { (gdb) bt #0 0x00000001000015d0 in c1::c1 (this=0x100003d08, __vtt_parm=0x100003450) at /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20121204/gcc/testsuite/g++.dg...
2012 Dec 04
3
[LLVMdev] radr://12777299, "potential pthread/eh bug exposed by libsanitizer"
Currently the replacement of allocation routines is based on creating a new malloc zone and a new CFAllocator (because the allocator replacement is done later than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of