diff mbox series

[v2,4/8] configure: Disable out-of-line atomic operations on Aarch64

Message ID 20220215170106.95848-5-f4bug@amsat.org (mailing list archive)
State New, archived
Headers show
Series buildsys: More fixes to use GCC on macOS | expand

Commit Message

Philippe Mathieu-Daudé Feb. 15, 2022, 5:01 p.m. UTC 
GCC 10.1 introduced the -moutline-atomics option on Aarch64.
This options is enabled by default, and triggers a link failure:

  Undefined symbols for architecture arm64:
    "___aarch64_cas1_acq_rel", referenced from:
        _qmp_migrate_recover in migration_migration.c.o
        _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
        _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
        _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
        _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
        _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
        _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
        ...
    "___aarch64_ldadd4_acq_rel", referenced from:
        _multifd_recv_new_channel in migration_multifd.c.o
        _monitor_event in monitor_hmp.c.o
        _handle_hmp_command in monitor_hmp.c.o
        _colo_compare_finalize in net_colo-compare.c.o
        _flatview_unref in softmmu_memory.c.o
        _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
        _tcg_register_thread in tcg_tcg.c.o
        ...
    "___aarch64_swp4_acq", referenced from:
        _qemu_spin_lock in softmmu_cpu-timers.c.o
        _cpu_get_ticks in softmmu_cpu-timers.c.o
        _qemu_spin_lock in softmmu_icount.c.o
        _cpu_exec in accel_tcg_cpu-exec.c.o
        _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
        _page_entry_lock in accel_tcg_translate-all.c.o
        _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
        ...

QEMU implements its own atomic operations using C11 builtin helpers.
Disable the GCC out-of-line atomic ops.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>

Clearly out of my understanding, but at least it links and the qtests
pass.
---
 configure | 12 ++++++++++++
 1 file changed, 12 insertions(+)

Comments

Akihiko Odaki Feb. 16, 2022, 2:41 a.m. UTC | #1 
On Wed, Feb 16, 2022 at 2:01 AM Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> GCC 10.1 introduced the -moutline-atomics option on Aarch64.
> This options is enabled by default, and triggers a link failure:
>
>   Undefined symbols for architecture arm64:
>     "___aarch64_cas1_acq_rel", referenced from:
>         _qmp_migrate_recover in migration_migration.c.o
>         _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
>         _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
>         _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
>         _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
>         _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
>         _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
>         ...
>     "___aarch64_ldadd4_acq_rel", referenced from:
>         _multifd_recv_new_channel in migration_multifd.c.o
>         _monitor_event in monitor_hmp.c.o
>         _handle_hmp_command in monitor_hmp.c.o
>         _colo_compare_finalize in net_colo-compare.c.o
>         _flatview_unref in softmmu_memory.c.o
>         _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
>         _tcg_register_thread in tcg_tcg.c.o
>         ...
>     "___aarch64_swp4_acq", referenced from:
>         _qemu_spin_lock in softmmu_cpu-timers.c.o
>         _cpu_get_ticks in softmmu_cpu-timers.c.o
>         _qemu_spin_lock in softmmu_icount.c.o
>         _cpu_exec in accel_tcg_cpu-exec.c.o
>         _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
>         _page_entry_lock in accel_tcg_translate-all.c.o
>         _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
>         ...
>
> QEMU implements its own atomic operations using C11 builtin helpers.
> Disable the GCC out-of-line atomic ops.
>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> Cc: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
>
> Clearly out of my understanding, but at least it links and the qtests
> pass.
> ---
>  configure | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/configure b/configure
> index 06c03cebd3..3217aa22cb 100755
> --- a/configure
> +++ b/configure
> @@ -2826,6 +2826,18 @@ else
>    avx512f_opt="no"
>  fi
>
> +#########################################
> +# Disable out-of-line atomic operations.
> +
> +case "$cpu" in
> +  aarch64)
> +    write_c_skeleton;
> +    if compile_prog "$CPU_CFLAGS -Werror -mno-outline-atomics" "" ; then
> +      CPU_CFLAGS="-mno-outline-atomics $CPU_CFLAGS"
> +    fi
> +    ;;
> +esac
> +
>  ########################################
>  # check if __[u]int128_t is usable.
>
> --
> 2.34.1
>

This change would (slightly) increase the code size and is harmful to
the other proper GCC installations. The flag should be specified by
the user (or the user should fix the GCC installation.)
Richard Henderson Feb. 16, 2022, 10:19 a.m. UTC | #2 
On 2/16/22 04:01, Philippe Mathieu-Daudé via wrote:
> GCC 10.1 introduced the -moutline-atomics option on Aarch64.
> This options is enabled by default, and triggers a link failure:
> 
>    Undefined symbols for architecture arm64:
>      "___aarch64_cas1_acq_rel", referenced from:
>          _qmp_migrate_recover in migration_migration.c.o
>          _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
>          _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
>          _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
>          _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
>          _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
>          _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
>          ...
>      "___aarch64_ldadd4_acq_rel", referenced from:
>          _multifd_recv_new_channel in migration_multifd.c.o
>          _monitor_event in monitor_hmp.c.o
>          _handle_hmp_command in monitor_hmp.c.o
>          _colo_compare_finalize in net_colo-compare.c.o
>          _flatview_unref in softmmu_memory.c.o
>          _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
>          _tcg_register_thread in tcg_tcg.c.o
>          ...
>      "___aarch64_swp4_acq", referenced from:
>          _qemu_spin_lock in softmmu_cpu-timers.c.o
>          _cpu_get_ticks in softmmu_cpu-timers.c.o
>          _qemu_spin_lock in softmmu_icount.c.o
>          _cpu_exec in accel_tcg_cpu-exec.c.o
>          _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
>          _page_entry_lock in accel_tcg_translate-all.c.o
>          _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
>          ...
> 
> QEMU implements its own atomic operations using C11 builtin helpers.
> Disable the GCC out-of-line atomic ops.
> 
> Signed-off-by: Philippe Mathieu-Daudé<f4bug@amsat.org>
> ---
> Cc: Stefan Hajnoczi<stefanha@redhat.com>
> Cc: Paolo Bonzini<pbonzini@redhat.com>
> 
> Clearly out of my understanding, but at least it links and the qtests
> pass.
> ---
>   configure | 12 ++++++++++++
>   1 file changed, 12 insertions(+)

These should have been supplied by libgcc.a, which we're supposed to be linking against. 
Something is wrong with your installation.


r~
Philippe Mathieu-Daudé Feb. 16, 2022, 3:08 p.m. UTC | #3 
On 16/2/22 11:19, Richard Henderson wrote:
> On 2/16/22 04:01, Philippe Mathieu-Daudé via wrote:
>> GCC 10.1 introduced the -moutline-atomics option on Aarch64.
>> This options is enabled by default, and triggers a link failure:
>>
>>    Undefined symbols for architecture arm64:
>>      "___aarch64_cas1_acq_rel", referenced from:
>>          _qmp_migrate_recover in migration_migration.c.o
>>          _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
>>          _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
>>          _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
>>          _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
>>          _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
>>          _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
>>          ...
>>      "___aarch64_ldadd4_acq_rel", referenced from:
>>          _multifd_recv_new_channel in migration_multifd.c.o
>>          _monitor_event in monitor_hmp.c.o
>>          _handle_hmp_command in monitor_hmp.c.o
>>          _colo_compare_finalize in net_colo-compare.c.o
>>          _flatview_unref in softmmu_memory.c.o
>>          _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
>>          _tcg_register_thread in tcg_tcg.c.o
>>          ...
>>      "___aarch64_swp4_acq", referenced from:
>>          _qemu_spin_lock in softmmu_cpu-timers.c.o
>>          _cpu_get_ticks in softmmu_cpu-timers.c.o
>>          _qemu_spin_lock in softmmu_icount.c.o
>>          _cpu_exec in accel_tcg_cpu-exec.c.o
>>          _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
>>          _page_entry_lock in accel_tcg_translate-all.c.o
>>          _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
>>          ...
>>
>> QEMU implements its own atomic operations using C11 builtin helpers.
>> Disable the GCC out-of-line atomic ops.
>>
>> Signed-off-by: Philippe Mathieu-Daudé<f4bug@amsat.org>
>> ---
>> Cc: Stefan Hajnoczi<stefanha@redhat.com>
>> Cc: Paolo Bonzini<pbonzini@redhat.com>
>>
>> Clearly out of my understanding, but at least it links and the qtests
>> pass.
>> ---
>>   configure | 12 ++++++++++++
>>   1 file changed, 12 insertions(+)
> 
> These should have been supplied by libgcc.a, which we're supposed to be 
> linking against. Something is wrong with your installation.

I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
compile these languages, but compiled C files using GCC. At the end the
Clang linker is used (the default c++ symlink).

Could there be a mismatch between Clang (-mno-outline-atomics) and GCC
(-moutline-atomics)?
Akihiko Odaki Feb. 16, 2022, 4:42 p.m. UTC | #4 
On 2022/02/17 0:08, Philippe Mathieu-Daudé wrote:
> On 16/2/22 11:19, Richard Henderson wrote:
>> On 2/16/22 04:01, Philippe Mathieu-Daudé via wrote:
>>> GCC 10.1 introduced the -moutline-atomics option on Aarch64.
>>> This options is enabled by default, and triggers a link failure:
>>>
>>>    Undefined symbols for architecture arm64:
>>>      "___aarch64_cas1_acq_rel", referenced from:
>>>          _qmp_migrate_recover in migration_migration.c.o
>>>          _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
>>>          _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
>>>          _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
>>>          _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
>>>          _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
>>>          _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
>>>          ...
>>>      "___aarch64_ldadd4_acq_rel", referenced from:
>>>          _multifd_recv_new_channel in migration_multifd.c.o
>>>          _monitor_event in monitor_hmp.c.o
>>>          _handle_hmp_command in monitor_hmp.c.o
>>>          _colo_compare_finalize in net_colo-compare.c.o
>>>          _flatview_unref in softmmu_memory.c.o
>>>          _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
>>>          _tcg_register_thread in tcg_tcg.c.o
>>>          ...
>>>      "___aarch64_swp4_acq", referenced from:
>>>          _qemu_spin_lock in softmmu_cpu-timers.c.o
>>>          _cpu_get_ticks in softmmu_cpu-timers.c.o
>>>          _qemu_spin_lock in softmmu_icount.c.o
>>>          _cpu_exec in accel_tcg_cpu-exec.c.o
>>>          _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
>>>          _page_entry_lock in accel_tcg_translate-all.c.o
>>>          _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
>>>          ...
>>>
>>> QEMU implements its own atomic operations using C11 builtin helpers.
>>> Disable the GCC out-of-line atomic ops.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé<f4bug@amsat.org>
>>> ---
>>> Cc: Stefan Hajnoczi<stefanha@redhat.com>
>>> Cc: Paolo Bonzini<pbonzini@redhat.com>
>>>
>>> Clearly out of my understanding, but at least it links and the qtests
>>> pass.
>>> ---
>>>   configure | 12 ++++++++++++
>>>   1 file changed, 12 insertions(+)
>>
>> These should have been supplied by libgcc.a, which we're supposed to 
>> be linking against. Something is wrong with your installation.
> 
> I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
> compile these languages, but compiled C files using GCC. At the end the
> Clang linker is used (the default c++ symlink).
> 
> Could there be a mismatch between Clang (-mno-outline-atomics) and GCC
> (-moutline-atomics)?

I think you have to instruct Clang to use libgcc instead of compiler-rt 
and link the objects with GCC. Here is the documentation of Clang about 
the runtime I could find:
https://clang.llvm.org/docs/Toolchain.html#libgcc-s-gnu
Philippe Mathieu-Daudé Feb. 16, 2022, 5:18 p.m. UTC | #5 
On 16/2/22 17:42, Akihiko Odaki wrote:
> On 2022/02/17 0:08, Philippe Mathieu-Daudé wrote:
>> On 16/2/22 11:19, Richard Henderson wrote:
>>> On 2/16/22 04:01, Philippe Mathieu-Daudé via wrote:
>>>> GCC 10.1 introduced the -moutline-atomics option on Aarch64.
>>>> This options is enabled by default, and triggers a link failure:
>>>>
>>>>    Undefined symbols for architecture arm64:
>>>>      "___aarch64_cas1_acq_rel", referenced from:
>>>>          _qmp_migrate_recover in migration_migration.c.o
>>>>          _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
>>>>          _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
>>>>          _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
>>>>          _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
>>>>          _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
>>>>          _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
>>>>          ...
>>>>      "___aarch64_ldadd4_acq_rel", referenced from:
>>>>          _multifd_recv_new_channel in migration_multifd.c.o
>>>>          _monitor_event in monitor_hmp.c.o
>>>>          _handle_hmp_command in monitor_hmp.c.o
>>>>          _colo_compare_finalize in net_colo-compare.c.o
>>>>          _flatview_unref in softmmu_memory.c.o
>>>>          _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
>>>>          _tcg_register_thread in tcg_tcg.c.o
>>>>          ...
>>>>      "___aarch64_swp4_acq", referenced from:
>>>>          _qemu_spin_lock in softmmu_cpu-timers.c.o
>>>>          _cpu_get_ticks in softmmu_cpu-timers.c.o
>>>>          _qemu_spin_lock in softmmu_icount.c.o
>>>>          _cpu_exec in accel_tcg_cpu-exec.c.o
>>>>          _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
>>>>          _page_entry_lock in accel_tcg_translate-all.c.o
>>>>          _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
>>>>          ...
>>>>
>>>> QEMU implements its own atomic operations using C11 builtin helpers.
>>>> Disable the GCC out-of-line atomic ops.
>>>>
>>>> Signed-off-by: Philippe Mathieu-Daudé<f4bug@amsat.org>
>>>> ---
>>>> Cc: Stefan Hajnoczi<stefanha@redhat.com>
>>>> Cc: Paolo Bonzini<pbonzini@redhat.com>
>>>>
>>>> Clearly out of my understanding, but at least it links and the qtests
>>>> pass.
>>>> ---
>>>>   configure | 12 ++++++++++++
>>>>   1 file changed, 12 insertions(+)
>>>
>>> These should have been supplied by libgcc.a, which we're supposed to 
>>> be linking against. Something is wrong with your installation.
>>
>> I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
>> compile these languages, but compiled C files using GCC. At the end the
>> Clang linker is used (the default c++ symlink).
>>
>> Could there be a mismatch between Clang (-mno-outline-atomics) and GCC
>> (-moutline-atomics)?
> 
> I think you have to instruct Clang to use libgcc instead of compiler-rt 
> and link the objects with GCC. Here is the documentation of Clang about 
> the runtime I could find:
> https://clang.llvm.org/docs/Toolchain.html#libgcc-s-gnu

Thanks for the pointer. And the next section is
https://clang.llvm.org/docs/Toolchain.html#atomics-library :)

   Clang does not currently automatically link against libatomic when
    using libgcc_s. You may need to manually add -latomic to support
   this configuration when using non-native atomic operations (if you
   see link errors referring to __atomic_* functions).

I'll try that.
Peter Maydell Feb. 16, 2022, 5:19 p.m. UTC | #6 
On Wed, 16 Feb 2022 at 17:18, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> Thanks for the pointer. And the next section is
> https://clang.llvm.org/docs/Toolchain.html#atomics-library :)
>
>    Clang does not currently automatically link against libatomic when
>     using libgcc_s. You may need to manually add -latomic to support
>    this configuration when using non-native atomic operations (if you
>    see link errors referring to __atomic_* functions).

We deliberately don't link against libatomic at the moment...

-- PMM
Richard Henderson Feb. 18, 2022, 1:46 a.m. UTC | #7 
On 2/17/22 04:18, Philippe Mathieu-Daudé wrote:
> On 16/2/22 17:42, Akihiko Odaki wrote:
>> On 2022/02/17 0:08, Philippe Mathieu-Daudé wrote:
>>> On 16/2/22 11:19, Richard Henderson wrote:
>>>> These should have been supplied by libgcc.a, which we're supposed to be linking 
>>>> against. Something is wrong with your installation.
>>>
>>> I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
>>> compile these languages, but compiled C files using GCC. At the end the
>>> Clang linker is used (the default c++ symlink).

This is another form of compiler mis-configuration.
If you don't have g++ to go with gcc, use --cxx=false to avoid picking up a different 
compiler.

>>> Could there be a mismatch between Clang (-mno-outline-atomics) and GCC
>>> (-moutline-atomics)?

I have no idea if those options do the same thing.

>> I think you have to instruct Clang to use libgcc instead of compiler-rt and link the 
>> objects with GCC. Here is the documentation of Clang about the runtime I could find:
>> https://clang.llvm.org/docs/Toolchain.html#libgcc-s-gnu
> 
> Thanks for the pointer. And the next section is
> https://clang.llvm.org/docs/Toolchain.html#atomics-library :)
> 
>    Clang does not currently automatically link against libatomic when
>     using libgcc_s. You may need to manually add -latomic to support
>    this configuration when using non-native atomic operations (if you
>    see link errors referring to __atomic_* functions).
> 
> I'll try that.

-moutline-atomics is *not* the same as libatomic.
You should not need libatomic at all.


r~
Paolo Bonzini Feb. 18, 2022, 3:36 p.m. UTC | #8 
On 2/18/22 02:46, Richard Henderson wrote:
>>>>
>>>> I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
>>>> compile these languages, but compiled C files using GCC. At the end the
>>>> Clang linker is used (the default c++ symlink).
> 
> This is another form of compiler mis-configuration.
> If you don't have g++ to go with gcc, use --cxx=false to avoid picking 
> up a different compiler.

This would be the kind of problem that this test is trying to cover:

     if do_cxx $CXXFLAGS $EXTRA_CXXFLAGS $CONFIGURE_CXXFLAGS $QEMU_CXXFLAGS -o $TMPE $TMPCXX $TMPO $QEMU_LDFLAGS; then
         # C++ compiler $cxx works ok with C compiler $cc
         :
     else
         echo "C++ compiler $cxx does not work with C compiler $cc"
         echo "Disabling C++ specific optional code"
         cxx=
     fi

In the past it detected issues with libasan/libtsan incompatibilities.
We should either add a test for atomic operations, or just drop the
test.

Paolo
Paolo Bonzini Feb. 18, 2022, 3:42 p.m. UTC | #9 
On 2/15/22 18:01, Philippe Mathieu-Daudé via wrote:
> +
> +case "$cpu" in
> +  aarch64)
> +    write_c_skeleton;
> +    if compile_prog "$CPU_CFLAGS -Werror -mno-outline-atomics" "" ; then
> +      CPU_CFLAGS="-mno-outline-atomics $CPU_CFLAGS"
> +    fi
> +    ;;

Apart from the question of whether/how to work around this issue, this 
should not be added to CPU_CFLAGS.  CPU_CFLAGS is only for things that 
change the ABI.

Paolo
Philippe Mathieu-Daudé March 6, 2022, 10:21 p.m. UTC | #10 
On 18/2/22 16:36, Paolo Bonzini wrote:
> On 2/18/22 02:46, Richard Henderson wrote:
>>>>>
>>>>> I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
>>>>> compile these languages, but compiled C files using GCC. At the end 
>>>>> the
>>>>> Clang linker is used (the default c++ symlink).
>>
>> This is another form of compiler mis-configuration.
>> If you don't have g++ to go with gcc, use --cxx=false to avoid picking 
>> up a different compiler.
> 
> This would be the kind of problem that this test is trying to cover:
> 
>      if do_cxx $CXXFLAGS $EXTRA_CXXFLAGS $CONFIGURE_CXXFLAGS 
> $QEMU_CXXFLAGS -o $TMPE $TMPCXX $TMPO $QEMU_LDFLAGS; then
>          # C++ compiler $cxx works ok with C compiler $cc
>          :
>      else
>          echo "C++ compiler $cxx does not work with C compiler $cc"
>          echo "Disabling C++ specific optional code"
>          cxx=
>      fi
> 
> In the past it detected issues with libasan/libtsan incompatibilities.
> We should either add a test for atomic operations, or just drop the
> test.

We shouldn't assume gcc is GCC:

$ c++ --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ clang --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
diff mbox series

Patch

diff --git a/configure b/configure
index 06c03cebd3..3217aa22cb 100755
--- a/configure
+++ b/configure
@@ -2826,6 +2826,18 @@  else
   avx512f_opt="no"
 fi
 
+#########################################
+# Disable out-of-line atomic operations.
+
+case "$cpu" in
+  aarch64)
+    write_c_skeleton;
+    if compile_prog "$CPU_CFLAGS -Werror -mno-outline-atomics" "" ; then
+      CPU_CFLAGS="-mno-outline-atomics $CPU_CFLAGS"
+    fi
+    ;;
+esac
+
 ########################################
 # check if __[u]int128_t is usable.