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: Tue, 27 May 2014 23:50:33 +0200
- Subject: Re: libsanitizer merge from upstream r208536
- Authentication-results: sourceware.org; auth=none
- References: <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> <CAGQ9bdx4aTvz_+5doCS3vg1QQ4BEQYriG7Rh-GtPShD-oTyRxg at mail dot gmail dot com> <20140526055736 dot GZ10386 at tucnak dot redhat dot com> <CAGQ9bdxVhRKefUUM8xtDzsNA2qaWTa4gM-o-t8az=o+MQbATUA at mail dot gmail dot com> <1401157537 dot 7849 dot 5 dot camel at otta> <20140527180707 dot GR10386 at tucnak dot redhat dot com> <1401224528 dot 7849 dot 15 dot camel at otta>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, May 27, 2014 at 04:02:08PM -0500, Peter Bergner wrote:
> It's being called form basically two files:
>
> [bergner@makalu-lp1 gcc-fsf-mainline-asan-debug]$ find . -name '*.o' | xargs nm -AC | grep sync_fetch_and_add_8
> ./powerpc64-linux/32/libsanitizer/sanitizer_common/.libs/sanitizer_allocator.o: U __sync_fetch_and_add_8
> ./powerpc64-linux/32/libsanitizer/sanitizer_common/sanitizer_allocator.o: U __sync_fetch_and_add_8
> ./powerpc64-linux/32/libsanitizer/asan/.libs/asan_allocator2.o: U __sync_fetch_and_add_8
> ./powerpc64-linux/32/libsanitizer/asan/asan_allocator2.o: U __sync_fetch_and_add_8
Does ppc32 have any atomic 64-bit loads/stores (in the sense that the aligned
64 bits are written as one memory transaction, not each 32-bit word
separately)?
In any case, atomic_uint64_t there seems to be used only for some statistic
counter and not really atomic anyway, as additions aren't performed using
atomic instructions, but just atomic load, followed by normal arithmetics,
followed by atomic store.
Can't 32-bit counters be used instead on 32-bit arches?
I see there is another spot with atomic_uint64_t in sanitizer_lfstack.h,
but for some reason it isn't used now at all (there it would want to use
64-bit compare and exchange).
Also note that the use of MMX (ugh) means that it is expensive (emms) and
will not work on pre-MMX chips.
Jakub