[PATCH] aarch64: fix check for SVE support in assembler

[PATCH] aarch64: fix check for SVE support in assembler

[Szabolcs Nagy]

Due to GCC bug 110901 -mcpu can override -march setting when compiling
asm code and thus a compiler targetting a specific cpu can fail the
configure check even when binutils gas supports SVE.

The workaround is that explicit .arch directive overrides both -mcpu
and -march, and since that's what the actual SVE memcpy uses the
configure check should use that too even if the GCC issue is fixed
independently.
---

note: i found this in yocto, and i think it's a better fix than
https://git.yoctoproject.org/poky/tree/meta/recipes-core/glibc/glibc/0023-aarch64-configure-Pass-mcpu-along-with-march-to-dete.patch

 sysdeps/aarch64/configure    | 5 +++--
 sysdeps/aarch64/configure.ac | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)
 mode change 100644 => 100755 sysdeps/aarch64/configure

diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure
old mode 100644
new mode 100755
index ca57edce47..9606137e8d
--- a/sysdeps/aarch64/configure
+++ b/sysdeps/aarch64/configure
@@ -325,9 +325,10 @@ then :
   printf %s "(cached) " >&6
 else $as_nop
   cat > conftest.s <<\EOF
-        ptrue p0.b
+	.arch armv8.2-a+sve
+	ptrue p0.b
 EOF
-if { ac_try='${CC-cc} -c -march=armv8.2-a+sve conftest.s 1>&5'
+if { ac_try='${CC-cc} -c conftest.s 1>&5'
   { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
   (eval $ac_try) 2>&5
   ac_status=$?
diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac
index 27874eceb4..56d12d661d 100644
--- a/sysdeps/aarch64/configure.ac
+++ b/sysdeps/aarch64/configure.ac
@@ -90,9 +90,10 @@ LIBC_CONFIG_VAR([aarch64-variant-pcs], [$libc_cv_aarch64_variant_pcs])
 # Check if asm support armv8.2-a+sve
 AC_CACHE_CHECK([for SVE support in assembler], [libc_cv_aarch64_sve_asm], [dnl
 cat > conftest.s <<\EOF
-        ptrue p0.b
+	.arch armv8.2-a+sve
+	ptrue p0.b
 EOF
-if AC_TRY_COMMAND(${CC-cc} -c -march=armv8.2-a+sve conftest.s 1>&AS_MESSAGE_LOG_FD); then
+if AC_TRY_COMMAND(${CC-cc} -c conftest.s 1>&AS_MESSAGE_LOG_FD); then
   libc_cv_aarch64_sve_asm=yes
 else
   libc_cv_aarch64_sve_asm=no
-- 
2.25.1

Re: [PATCH] aarch64: fix check for SVE support in assembler

[Florian Weimer]

* Szabolcs Nagy:

> Due to GCC bug 110901 -mcpu can override -march setting when compiling
> asm code and thus a compiler targetting a specific cpu can fail the
> configure check even when binutils gas supports SVE.
>
> The workaround is that explicit .arch directive overrides both -mcpu
> and -march, and since that's what the actual SVE memcpy uses the
> configure check should use that too even if the GCC issue is fixed
> independently.
> ---
>
> note: i found this in yocto, and i think it's a better fix than
> https://git.yoctoproject.org/poky/tree/meta/recipes-core/glibc/glibc/0023-aarch64-configure-Pass-mcpu-along-with-march-to-dete.patch

Mechanics look reasonable.

Reviewed-by: Florian Weimer <fweimer@redhat.com>

Thanks,
Florian

Re: [PATCH] aarch64: fix check for SVE support in assembler

[Khem Raj]

On Thu, Mar 14, 2024 at 6:57 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Szabolcs Nagy:
>
> > Due to GCC bug 110901 -mcpu can override -march setting when compiling
> > asm code and thus a compiler targetting a specific cpu can fail the
> > configure check even when binutils gas supports SVE.
> >
> > The workaround is that explicit .arch directive overrides both -mcpu
> > and -march, and since that's what the actual SVE memcpy uses the
> > configure check should use that too even if the GCC issue is fixed
> > independently.
> > ---
> >
> > note: i found this in yocto, and i think it's a better fix than
> > https://git.yoctoproject.org/poky/tree/meta/recipes-core/glibc/glibc/0023-aarch64-configure-Pass-mcpu-along-with-march-to-dete.patch
>
> Mechanics look reasonable.
>
> Reviewed-by: Florian Weimer <fweimer@redhat.com>

LGTM, the yocto patch was just a workaround to wait on GCC to fix the
problem, but this solves is properly within glibc and does not
need to wait on gcc fix. I will test it out.

>
> Thanks,
> Florian
>