This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libsanitizer merge from upstream r208536
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Peter Bergner <bergner at vnet dot ibm dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dodji Seketeli <dodji at redhat dot com>, Dmitry Vyukov <dvyukov at google dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Fri, 23 May 2014 21:34:33 +0200
- Subject: Re: libsanitizer merge from upstream r208536
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdxH9rh0Cz8LBYZsuHKEFpkVosNkX2qrX10RGwK5hFEEqg at mail dot gmail dot com> <20140523134107 dot GC17600 at redhat dot com> <CAGQ9bdyPk5MmNDvpdkqkx=bXjSM6wO76dUwyPa0Krrp_OTjXfw at mail dot gmail dot com> <1400855109 dot 12948 dot 146 dot camel at otta> <1400863633 dot 12948 dot 152 dot camel at otta> <1400871287 dot 12948 dot 160 dot camel at otta>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Fri, May 23, 2014 at 01:54:47PM -0500, Peter Bergner wrote:
> On Fri, 2014-05-23 at 11:47 -0500, Peter Bergner wrote:
> > The following patch gets bootstrap working again, but there seems to
> > be a large number of testsuite failures I will look into before
> > submitting the patch to the LLVM mailing list.
>
> FYI, it looks like a huge number of the failures are from the following
> in 32-bit mode:
>
> /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug/powerpc64-linux/32/libsanitizer/asan/.libs/libasan.so: undefined reference to `__sync_fetch_and_add_8'^M
> collect2: error: ld returned 1 exit status^M
>
> Kosta, we don't have a __sync_fetch_and_add_8 in 32-bit, since
> we don't have the necessary hardware instructions to do a 64-bit
> fetch and add. How is this supposed to work? There are some
> libatomic routines we could call (eg, __atomic_fetch_add_8).
But libatomic in the end for that cases uses locking and non-atomic access
anyway. On i?86 64-bit atomics are available starting with i586,
on sparc starting with v9, but I believe on most architectures
if you have atomics at all you don't have atomics larger than word size.
For GCC, if you want in the preprocessor to test if a CPU has 64-bit
atomics, you'd check #ifdef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
Can you use locking instead otherwise?
Jakub