This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libsanitizer merge from upstream r208536
- From: Dmitry Vyukov <dvyukov at google dot com>
- To: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- Cc: ramrad01 at arm dot com, Jakub Jelinek <jakub at redhat dot com>, Peter Bergner <bergner at vnet dot ibm dot com>, Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dodji Seketeli <dodji at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Yuri Gribov <tetra2005 at gmail dot com>
- Date: Wed, 28 May 2014 19:30:30 +0400
- Subject: Re: libsanitizer merge from upstream r208536
- Authentication-results: sourceware.org; auth=none
- References: <1400855109 dot 12948 dot 146 dot camel at otta> <1400863633 dot 12948 dot 152 dot camel at otta> <1400871287 dot 12948 dot 160 dot camel at otta> <CAGQ9bdx4aTvz_+5doCS3vg1QQ4BEQYriG7Rh-GtPShD-oTyRxg at mail dot gmail dot com> <20140526055736 dot GZ10386 at tucnak dot redhat dot com> <CAGQ9bdxVhRKefUUM8xtDzsNA2qaWTa4gM-o-t8az=o+MQbATUA at mail dot gmail dot com> <1401157537 dot 7849 dot 5 dot camel at otta> <20140527180707 dot GR10386 at tucnak dot redhat dot com> <1401224528 dot 7849 dot 15 dot camel at otta> <20140527215033 dot GS10386 at tucnak dot redhat dot com> <20140527220023 dot GT10386 at tucnak dot redhat dot com> <CAJA7tRZLqr0UxD0nteY=9o4izk9SvDYQOQdypLjNpRMikZWd_A at mail dot gmail dot com> <CAGQ9bdy1dnKWh_D=uqDeFC6Yjtj3ESasGPxq2z6W6zuvpZrhJw at mail dot gmail dot com>
On Wed, May 28, 2014 at 8:36 AM, Konstantin Serebryany
<konstantin.s.serebryany@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.gcc@googlemail.com> wrote:
>> On Tue, May 27, 2014 at 11:00 PM, Jakub Jelinek <jakub@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