On Thu, 14 Sept 2023 at 08:44, Christophe Lyon
<christophe.l...@linaro.org> wrote:
>
> Hi,
>
>
> On Wed, 13 Sept 2023 at 14:32, Jonathan Wakely <jwak...@redhat.com> wrote:
>>
>> Tested x86_64-linux and aarch64-linux. I intend to push this to trunk.
>>
>> -- >8 --
>>
>> These atomics cause linker errors on arm4t where __sync_synchronize is
>> not defined. For single-threaded targets we don't need the atomics.
>>
>
> I ran the tests on arm-eabi default config (so, armv4t) with this patch, and 
> here is the list of remaining UNRESOLVED tests:
>  29_atomics/atomic/compare_exchange_padding.cc
> 29_atomics/atomic/cons/value_init.cc
> 29_atomics/atomic_float/value_init.cc
> 29_atomics/atomic_integral/cons/value_init.cc
> 29_atomics/atomic_ref/compare_exchange_padding.cc
> 29_atomics/atomic_ref/generic.cc
> 29_atomics/atomic_ref/integral.cc
> 29_atomics/atomic_ref/pointer.cc
> experimental/polymorphic_allocator/construct_pair.cc
>
> all of them are due to undefined reference to __sync_synchronize
> (some also reference __atomic_compare_exchange_4, etc...)
>
>
> IIUC, this should not be the case for 
> experimental/polymorphic_allocator/construct_pair.cc ?
> The reference for __sync_synchronize is near the beginning of test0[123]
> from a call to __atomic_load_n line 835 of atomic_base.h
> not sure where it comes from, the .loc directive indicates line 28 of the 
> testcase which is the opening brace

Doh, I removed the atomics from <memory_resource> but this is
<experimental/memory_resource>, which has a separate implementation.

I'll make a change to <experimental/memory_resource> as well, thanks
for catching my silly mistake.

Reply via email to