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, May 27, 2014 at 05:04:52PM -0500, Peter Bergner wrote:
> 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.

OT, if lfd/stfd is atomic (perhaps on a subset of CPUs), why doesn't
config/rs6000/ implement 32-bit atomic_{load,store}di using
that insn?

Though, e.g.
suggests that it might not be atomic on some CPUs.


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