On Wed, May 28, 2014 at 8:36 AM, Konstantin Serebryany <konstantin.s.serebry...@gmail.com> wrote: > Dmitry, > You've introduced atomic_uint64_t stats_[AllocatorStatCount]; in > http://llvm.org/viewvc/llvm-project?view=revision&revision=173332 > Do you mind to change it to atomic_uintptr_t? > There is of course a chance of overflow on 32-bit arch (the number of > mallocs in a process may easily go over 2^32 in a long run), > but this is just stats, I think we can tolerate it.
I removed 64-bit atomics from stats in llvm r209744. > On Wed, May 28, 2014 at 2:41 AM, Ramana Radhakrishnan > <ramana....@googlemail.com> wrote: >> On Tue, May 27, 2014 at 11:00 PM, Jakub Jelinek <ja...@redhat.com> wrote: >>> 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 >> >> FTR, this call down to the library function should only be for legacy >> architectures. >> >> On ARM we have a 64 bit atomic compare and exchange which can be done >> with the ldrexd / strexd instructions at the right architecture level >> (v6k and above IIRC). >> >> Ramana
