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

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.


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