On Tue, May 27, 2014 at 11:50:33PM +0200, Jakub Jelinek wrote: > 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).
On ARM, while it supposedly links, because __sync_compare_and_exchange_8 is defined in libgcc.a, it will only work with post-2011 kernels and is going to be very slow (because you do a separate compare and exchange to load and separate compare and exchange to store, i.e. twice as much effort to actually not achieve atomicity, sometimes even 2 syscalls). Jakub