This is the mail archive of the gcc-patches@gcc.gnu.org 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


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


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