This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libsanitizer merge from upstream r208536

You've introduced   atomic_uint64_t stats_[AllocatorStatCount]; in
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.


On Wed, May 28, 2014 at 2:41 AM, Ramana Radhakrishnan
<> wrote:
> On Tue, May 27, 2014 at 11:00 PM, Jakub Jelinek <> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]