Re: [PATCH 2/2] meson: fix CONFIG_ATOMIC128 check

[Peter Maydell]

On Mon, 28 Feb 2022 at 13:28, Marc-André Lureau
<marcandre.lureau@redhat.com> wrote:
>
> Hi
>
> On Mon, Feb 28, 2022 at 5:24 PM Peter Maydell <peter.maydell@linaro.org> 
> wrote:
> >
> > On Mon, 28 Feb 2022 at 12:19, <marcandre.lureau@redhat.com> wrote:
> > >
> > > From: Marc-André Lureau <marcandre.lureau@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