summaryrefslogtreecommitdiffstats
path: root/meson.build
diff options
context:
space:
mode:
authorMarc-André Lureau2022-02-28 13:03:09 +0100
committerMarc-André Lureau2022-03-22 11:46:17 +0100
commitd2958fb0b6c7bcd8c4e6c0222554ef25d62ecef0 (patch)
treef57b41524d95062f466ee046304406cf180ebfa7 /meson.build
parentmeson: move int128 checks from configure (diff)
downloadqemu-d2958fb0b6c7bcd8c4e6c0222554ef25d62ecef0.tar.gz
qemu-d2958fb0b6c7bcd8c4e6c0222554ef25d62ecef0.tar.xz
qemu-d2958fb0b6c7bcd8c4e6c0222554ef25d62ecef0.zip
meson: fix CONFIG_ATOMIC128 check
The current testing code isn't correct and matching QEMU usage: testfile.c: In function 'main': testfile.c:5:11: error: incorrect number of arguments to function '__atomic_load' 5 | y = __atomic_load(&x, 0); | ^~~~~~~~~~~~~ testfile.c:6:7: error: argument 2 of '__atomic_store' must be a pointer type 6 | __atomic_store(&x, y, 0); | ^~~~~~~~~~~~~~ testfile.c:7:7: error: argument 3 of '__atomic_compare_exchange' must be a pointer type 7 | __atomic_compare_exchange(&x, &y, x, 0, 0, 0); | ^~~~~~~~~~~~~~~~~~~~~~~~~ Replace the test with common atomics test for u64 and u128 that matches better QEMU needs. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Diffstat (limited to 'meson.build')
-rw-r--r--meson.build27
1 files changed, 12 insertions, 15 deletions
diff --git a/meson.build b/meson.build
index 85f3f84ec6..58520aab50 100644
--- a/meson.build
+++ b/meson.build
@@ -1853,21 +1853,23 @@ config_host_data.set('HAVE_BROKEN_SIZE_MAX', not cc.compiles('''
return printf("%zu", SIZE_MAX);
}''', args: ['-Werror']))
-# See if 64-bit atomic operations are supported.
-# Note that without __atomic builtins, we can only
-# assume atomic loads/stores max at pointer size.
-config_host_data.set('CONFIG_ATOMIC64', cc.links('''
+atomic_test = '''
#include <stdint.h>
int main(void)
{
- uint64_t x = 0, y = 0;
+ @0@ x = 0, y = 0;
y = __atomic_load_n(&x, __ATOMIC_RELAXED);
__atomic_store_n(&x, y, __ATOMIC_RELAXED);
__atomic_compare_exchange_n(&x, &y, x, 0, __ATOMIC_RELAXED, __ATOMIC_RELAXED);
__atomic_exchange_n(&x, y, __ATOMIC_RELAXED);
__atomic_fetch_add(&x, y, __ATOMIC_RELAXED);
return 0;
- }'''))
+ }'''
+
+# See if 64-bit atomic operations are supported.
+# Note that without __atomic builtins, we can only
+# assume atomic loads/stores max at pointer size.
+config_host_data.set('CONFIG_ATOMIC64', cc.links(atomic_test.format('uint64_t')))
has_int128 = cc.links('''
__int128_t a;
@@ -1882,15 +1884,10 @@ has_int128 = cc.links('''
config_host_data.set('CONFIG_INT128', has_int128)
if has_int128
- has_atomic128 = cc.links('''
- int main(void)
- {
- unsigned __int128 x = 0, y = 0;
- y = __atomic_load(&x, 0);
- __atomic_store(&x, y, 0);
- __atomic_compare_exchange(&x, &y, x, 0, 0, 0);
- return 0;
- }''')
+ # "do we have 128-bit atomics which are handled inline and specifically not
+ # via libatomic". The reason we can't use libatomic is documented in the
+ # comment starting "GCC is a house divided" in include/qemu/atomic128.h.
+ has_atomic128 = cc.links(atomic_test.format('unsigned __int128'))
config_host_data.set('CONFIG_ATOMIC128', has_atomic128)