On Tue, 2014-05-27 at 23:50 +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)?
The only option I can think of would be using the floating point load/store instructions lfd/stfd. Of course if we're going to operate on them, then we'd need to copy them back to memory and then into the integer registers again....before copying them back to the FP registers (thru memory again) so we can store them with the stfd. > 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? Using 32-bit counters would be easiest if we can, but Kostya will have to answer that. Peter
