Date: Wed, 11 Sep 2013 00:23:20 +0100 From: Andrew Turner <andrew@fubar.geek.nz> To: Ed Schouten <ed@80386.nl> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>, George Mitchell <george@m5p.com> Subject: Re: Failure compiling glib20 on ARM Message-ID: <20130911002320.0f05b836@bender.Home> In-Reply-To: <CAJOYFBB7FGhUeAyCoiDCMd%2B0tSPXKoHLzbs2GkbG3Qj-NkEk8g@mail.gmail.com> References: <522C592C.5010800@m5p.com> <20130909231720.5b2c4823@bender.Home> <CAJOYFBB7FGhUeAyCoiDCMd%2B0tSPXKoHLzbs2GkbG3Qj-NkEk8g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 10 Sep 2013 22:24:47 +0200
Ed Schouten <ed@80386.nl> wrote:
> Hi Andrew,
>
> 2013/9/10 Andrew Turner <andrew@fubar.geek.nz>:
> > I don't see support for it in our stdatomic functions. It shouldn't
> > be too hard to support, a simple would be something like:
> >
> > int __sync_bool_compare_and_swap_4(uint32_t *mem, uint32_t expected,
> > uint32_t new)
> > {
> > return (__sync_val_compare_and_swap_4(mem, expected, new) ==
> > expected);
> > }
>
> My initial goal was to just add the atomic intrinsics to make the C11
> standards atomic interface work (<stdatomic.h>). That's why I am
> personally not that interested in adding all sorts of extra `bloat';
> code should just use <stdatomic.h> instead.
>
> Still, if there is a strong interest in adding this function as well,
> be sure to send me a patch for sys/*/*/stdatomic.c and I would be more
> than willing to review it.
It looks like clang handles these gcc builtins by generating the
appropriate code without calling an external function. The version of
gcc we have in the tree will generate a call.
If nobody wishes to support our version of gcc on ARM then the only
solutions are to use clang to build glib, or fix the port to use
the __sync_val_compare_and_swap builtin.
Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130911002320.0f05b836>