On Mon, 28 Feb 2022 at 13:28, Marc-André Lureau <marcandre.lur...@redhat.com> wrote: > > Hi > > On Mon, Feb 28, 2022 at 5:24 PM Peter Maydell <peter.mayd...@linaro.org> > wrote: > > > > On Mon, 28 Feb 2022 at 12:19, <marcandre.lur...@redhat.com> wrote: > > > > > > From: Marc-André Lureau <marcandre.lur...@redhat.com> > > > > > > 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); > > > | ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > And it must be linked with -latomic. > > > > As Philippe says, this isn't right. What the configure test > > is checking for is "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. > > The arguments fix is still valid, no?
Probably. (Does this mean we've never been correctly setting CONFIG_ATOMIC128?) I think we should have the 128-bit atomics check in meson.build look the same as the existing one for 64-bit atomics, though, unless there's a reason why they should look different. For the 64-bit version we explicitly pass __ATOMIC_RELAXED, and we use __atomic_load_n(), not __atomic_load(). thanks -- PMM
