[1/4] arm: Install __sync libfuncs for Linux.

Cc: Richard Earnshaw <richard.earnshaw@arm.com>
Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
---
 gcc/config/arm/arm.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

On 11 November 2011 23:32, Richard Henderson <rth@redhat.com> wrote:
> Cc: Richard Earnshaw <richard.earnshaw@arm.com>
> Cc: Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
> ---
>  gcc/config/arm/arm.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 6ef6f62..abf8ce1 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -1096,6 +1096,10 @@ arm_set_fixed_conv_libfunc (convert_optab optable, enum machine_mode to,
>  static void
>  arm_init_libfuncs (void)
>  {
> +  /* For Linux, we have access to kernel support for atomic operations.  */
> +  if (arm_abi == ARM_ABI_AAPCS_LINUX)
> +    init_sync_libfuncs (8);

There is unfortunately no guarantee that your kernel has support for the 64bit
cases, since this was only recently added - and the libgcc code checks
and aborts if linked in.

(As far as I can tell there is approximately one potential user of 64bit atomics
on ARM, so it's important not to do that check for all binaries).

Dave

On 11/14/2011 08:08 AM, David Gilbert wrote:
> There is unfortunately no guarantee that your kernel has support for the 64bit
> cases, since this was only recently added - and the libgcc code checks
> and aborts if linked in.
> 
> (As far as I can tell there is approximately one potential user of 64bit atomics
> on ARM, so it's important not to do that check for all binaries).

Yes, I know.  But that's something the user had to deal with before my patch too.
But if I just put UNITS_PER_WORD there, you'll won't be able to use those routines
even if the kernel support is present.

This is something that is more ideally handled by the atomics library that is
being discussed; __atomic_is_lock_free would be able to query the existence of
the kernel support in reporting its result.

Andrew, what's the state of discussion on the atomics library?  While I 
understand that vendors want to be able to replace that library, and thus we
want to settle on a standard ABI, I think *not* providing at least a reference
copy with GCC is almost certainly a mistake.


r~

>
> There is unfortunately no guarantee that your kernel has support for the 64bit
> cases, since this was only recently added - and the libgcc code checks
> and aborts if linked in.

I don't see how this patch will change status-quo.

Richard: I've not been able to test the patch yet given that trunk is
broken for arm-linux-gnueabi currently. I will probably have to try
doing this sometime later tonight or so.

cheers
Ramana

On 11/14/2011 01:18 PM, Richard Henderson wrote:
> On 11/14/2011 08:08 AM, David Gilbert wrote:
>
> Andrew, what's the state of discussion on the atomics library?  While I
> understand that vendors want to be able to replace that library, and thus we
> want to settle on a standard ABI, I think *not* providing at least a reference
> copy with GCC is almost certainly a mistake.

There should be one sometime in the next few weeks...  I have no 
intention of providing a compiler without SOMETHING that people can 
acquire and build.  It just may not be part of the compiler, but will be 
easily available.

Andrew