This is the mail archive of the
mailing list for the GCC project.
Re: libsanitizer merge from upstream r208536
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Peter Bergner <bergner at vnet dot ibm dot com>
- Cc: Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jakub Jelinek <jakub at redhat dot com>, 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: Mon, 26 May 2014 08:57:11 +0400
- 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>
Last time I tried, asan did not work on ppc32 for a large number of
In upstream build system ppc32 is simply disabled, so imho it should
be also disabled in the GCC build.
If there is enough interest in ppc32, please work with up on fixing
upstream and enabling the build bots --
then we can talk about supporting ppc32 in GCC (it will actually come
for free then).
(I can't say whether ppc64 works today, but at least it worked for me
at some point).
On Fri, May 23, 2014 at 10:54 PM, Peter Bergner <email@example.com> 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).
> Is that an option? ...or maybe we shouldn't even be attempting
> call a 64-bit fetch/add for things larger than a register size?