Message ID | alpine.DEB.2.20.1706202038480.3448@digraph.polyomino.org.uk |
---|---|
State | New |
Headers | show |
Ping. This patch <https://sourceware.org/ml/libc-alpha/2017-06/msg00960.html> is pending review.
On Tue, Jun 20, 2017 at 1:45 PM, Joseph Myers <joseph@codesourcery.com> wrote: > This patch implements a requirement of binutils >= 2.25 (up from 2.22) > to build glibc. Tests for 2.24 or later on x86_64 and s390 are > removed. It was already the case, as indicated by buildbot results, > that 2.24 was too old for building tests for 32-bit x86 (produced > internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know > if any configure tests for binutils features are obsolete given the > increased version requirement. > > Tested for x86_64. > > 2017-06-20 Joseph Myers <joseph@codesourcery.com> > > * configure.ac (AS): Require binutils 2.25 or later. > (LD): Likewise. > * configure: Regenerated. > * sysdeps/s390/configure.ac (AS): Remove version check. > * sysdeps/s390/configure: Regenerated. > * sysdeps/x86_64/configure.ac (AS): Remove version check. > * sysdeps/x86_64/configure: Regenerated. > * manual/install.texi (Tools for Compilation): Document > requirement for binutils 2.25 or later. > * INSTALL: Regenerated. > > diff --git a/configure.ac b/configure.ac > index 16e97d3..db1ea40 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1071,14 +1071,14 @@ AC_PROG_LN_S > > LIBC_PROG_BINUTILS > > -# Accept binutils 2.22 or newer. > +# Accept binutils 2.25 or newer. > AC_CHECK_PROG_VER(AS, $AS, --version, > [GNU assembler.* \([0-9]*\.[0-9.]*\)], > - [2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], > + [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], > AS=: critic_missing="$critic_missing as") > AC_CHECK_PROG_VER(LD, $LD, --version, > [GNU ld.* \([0-9][0-9]*\.[0-9.]*\)], > - [2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], > + [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], > LD=: critic_missing="$critic_missing ld") > > # These programs are version sensitive. Should we also allow gold 1.14 or above to build glibc? After commit 388b4f1a02f3a801965028bbfcd48d905638b797 Author: H.J. Lu <hjl.tools@gmail.com> Date: Fri Jun 23 14:38:46 2017 -0700 Avoid .symver on common symbols [BZ #21666] The .symver directive on common symbol just creates a new common symbol, not an alias and the newer assembler with the bug fix for gold 1.14 can build glibc with a few "make check" errors: https://sourceware.org/bugzilla/show_bug.cgi?id=21674
On 06/26/2017 02:46 PM, H.J. Lu wrote: > Should we also allow gold 1.14 or above to build glibc? After > > commit 388b4f1a02f3a801965028bbfcd48d905638b797 > Author: H.J. Lu <hjl.tools@gmail.com> > Date: Fri Jun 23 14:38:46 2017 -0700 > > Avoid .symver on common symbols [BZ #21666] > > The .symver directive on common symbol just creates a new common symbol, > not an alias and the newer assembler with the bug fix for > > gold 1.14 can build glibc with a few "make check" errors: > > https://sourceware.org/bugzilla/show_bug.cgi?id=21674 Do you know if the tests are miscompiled, or if glibc itself is broken? In case the latter, we should back out the change to accept gold if this cannot be fixed before the release. Thanks, Florian
On Mon, Jun 26, 2017 at 5:49 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 06/26/2017 02:46 PM, H.J. Lu wrote: >> Should we also allow gold 1.14 or above to build glibc? After >> >> commit 388b4f1a02f3a801965028bbfcd48d905638b797 >> Author: H.J. Lu <hjl.tools@gmail.com> >> Date: Fri Jun 23 14:38:46 2017 -0700 >> >> Avoid .symver on common symbols [BZ #21666] >> >> The .symver directive on common symbol just creates a new common symbol, >> not an alias and the newer assembler with the bug fix for >> >> gold 1.14 can build glibc with a few "make check" errors: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=21674 > > Do you know if the tests are miscompiled, or if glibc itself is broken? Most of tests are OK. But some tests are linked incorrectly by gold. > In case the latter, we should back out the change to accept gold if this > cannot be fixed before the release. Gold isn't allowed to build glibc as of today. Because of it, no one was aware of gold bugs exposed by "make check" in glibc.
On 06/26/2017 03:11 PM, H.J. Lu wrote:
> Most of tests are OK. But some tests are linked incorrectly by gold.
Okay, if it's just tests which are wrong, that's probably okay.
Thanks,
Florian
On Wed, 28 Jun 2017, Florian Weimer wrote: > On 06/26/2017 03:11 PM, H.J. Lu wrote: > > Most of tests are OK. But some tests are linked incorrectly by gold. > > Okay, if it's just tests which are wrong, that's probably okay. Can someone review my actual patch to require binutils 2.25, independent of any proposal to allow some set of versions of gold?
On 06/20/2017 10:45 PM, Joseph Myers wrote: > This patch implements a requirement of binutils >= 2.25 (up from 2.22) > to build glibc. Tests for 2.24 or later on x86_64 and s390 are > removed. It was already the case, as indicated by buildbot results, > that 2.24 was too old for building tests for 32-bit x86 (produced > internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know > if any configure tests for binutils features are obsolete given the > increased version requirement. Can we make 2.25.1 the minimum version? Then we can drop the check in sysdeps/arm/configure.ac, too. Thanks, Florian
On Wed, 28 Jun 2017, Florian Weimer wrote: > On 06/20/2017 10:45 PM, Joseph Myers wrote: > > This patch implements a requirement of binutils >= 2.25 (up from 2.22) > > to build glibc. Tests for 2.24 or later on x86_64 and s390 are > > removed. It was already the case, as indicated by buildbot results, > > that 2.24 was too old for building tests for 32-bit x86 (produced > > internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know > > if any configure tests for binutils features are obsolete given the > > increased version requirement. > > Can we make 2.25.1 the minimum version? Then we can drop the check in > sysdeps/arm/configure.ac, too. I'm wary of testing for minor versions like that; it's entirely plausible someone may have particular bug fixes from later on the release branch without necessarily having the higher version number.
On Wed, Jun 28, 2017 at 3:30 AM, Joseph Myers <joseph@codesourcery.com> wrote: > On Wed, 28 Jun 2017, Florian Weimer wrote: > >> On 06/26/2017 03:11 PM, H.J. Lu wrote: >> > Most of tests are OK. But some tests are linked incorrectly by gold. >> >> Okay, if it's just tests which are wrong, that's probably okay. > > Can someone review my actual patch to require binutils 2.25, independent > of any proposal to allow some set of versions of gold? > LGTM. Thanks.
On 06/28/2017 06:58 AM, Joseph Myers wrote: > On Wed, 28 Jun 2017, Florian Weimer wrote: > >> On 06/20/2017 10:45 PM, Joseph Myers wrote: >>> This patch implements a requirement of binutils >= 2.25 (up from 2.22) >>> to build glibc. Tests for 2.24 or later on x86_64 and s390 are >>> removed. It was already the case, as indicated by buildbot results, >>> that 2.24 was too old for building tests for 32-bit x86 (produced >>> internal linker errors linking elf/tst-gnu2-tls1mod.so). I don't know >>> if any configure tests for binutils features are obsolete given the >>> increased version requirement. >> >> Can we make 2.25.1 the minimum version? Then we can drop the check in >> sysdeps/arm/configure.ac, too. > > I'm wary of testing for minor versions like that; it's entirely plausible > someone may have particular bug fixes from later on the release branch > without necessarily having the higher version number. Are you suggesting you want to support a vendor "2.25" that has bug fixes that has equivalent functionality to 2.25.1? Why wouldn't such a vendor simply update to 2.25.1? Particularly if they cared about ARM? The upstream FSF versions have a very specific meaning. We should not be confusing this with vendor branches and what they provide.
On Wed, 28 Jun 2017, Carlos O'Donell wrote: > >> Can we make 2.25.1 the minimum version? Then we can drop the check in > >> sysdeps/arm/configure.ac, too. > > > > I'm wary of testing for minor versions like that; it's entirely plausible > > someone may have particular bug fixes from later on the release branch > > without necessarily having the higher version number. > > Are you suggesting you want to support a vendor "2.25" that has bug fixes > that has equivalent functionality to 2.25.1? > > Why wouldn't such a vendor simply update to 2.25.1? Particularly if they > cared about ARM? > > The upstream FSF versions have a very specific meaning. We should not be > confusing this with vendor branches and what they provide. I'm suggesting that (a) it's normal for specific bug fixes to get backported for GCC and binutils (and for that matter the Linux kernel), so that the low part of the version number may not always be very meaningful for configure tests in indicating what is or is not supported - and sometimes a version number may be deliberately adjusted to ensure that e.g. files are installed in the same place after an update as before (I don't know if that's done specifically for binutils, but if you supported people linking with a shared libbfd you might not want to change the version number for bug fixes), and (b) we do generally hope things will work with whatever recent-enough tools people have installed, and the version checks are generally expected to work with such tools (modulo e.g. the case of a warning option being backported and the __GNUC_PREREQ conditionals for disabling it being based on the upstream version). And (c) testing for the low part complicates the patterns used to test for version numbers, without much corresponding benefit.
On 06/28/2017 09:29 AM, Joseph Myers wrote: > On Wed, 28 Jun 2017, Carlos O'Donell wrote: > >>>> Can we make 2.25.1 the minimum version? Then we can drop the check in >>>> sysdeps/arm/configure.ac, too. >>> >>> I'm wary of testing for minor versions like that; it's entirely plausible >>> someone may have particular bug fixes from later on the release branch >>> without necessarily having the higher version number. >> >> Are you suggesting you want to support a vendor "2.25" that has bug fixes >> that has equivalent functionality to 2.25.1? >> >> Why wouldn't such a vendor simply update to 2.25.1? Particularly if they >> cared about ARM? >> >> The upstream FSF versions have a very specific meaning. We should not be >> confusing this with vendor branches and what they provide. > > I'm suggesting that (a) it's normal for specific bug fixes to get > backported for GCC and binutils (and for that matter the Linux kernel), so > that the low part of the version number may not always be very meaningful > for configure tests in indicating what is or is not supported - and > sometimes a version number may be deliberately adjusted to ensure that > e.g. files are installed in the same place after an update as before (I > don't know if that's done specifically for binutils, but if you supported > people linking with a shared libbfd you might not want to change the > version number for bug fixes), and (b) we do generally hope things will > work with whatever recent-enough tools people have installed, and the > version checks are generally expected to work with such tools (modulo e.g. > the case of a warning option being backported and the __GNUC_PREREQ > conditionals for disabling it being based on the upstream version). And > (c) testing for the low part complicates the patterns used to test for > version numbers, without much corresponding benefit. I agree with (c), and I also agree that making the public statement "We support 2.25" is the simplest message we can send. I expect the ARM configure clenaup can happen when we eventually require a newer version.
On 06/28/2017 03:55 PM, Carlos O'Donell wrote: > I agree with (c), and I also agree that making the public statement > "We support 2.25" is the simplest message we can send. > > I expect the ARM configure clenaup can happen when we eventually require > a newer version. Okay, let's do it this way (using Joseph's original patch). Thanks, Florian
diff --git a/INSTALL b/INSTALL index 71af35b..ccd3a2e 100644 --- a/INSTALL +++ b/INSTALL @@ -443,7 +443,7 @@ build the GNU C Library: Check the FAQ for any special compiler issues on particular platforms. - * GNU 'binutils' 2.22 or later + * GNU 'binutils' 2.25 or later You must use GNU 'binutils' (as and ld) to build the GNU C Library. No other assembler or linker has the necessary functionality at the diff --git a/NEWS b/NEWS index 4db334b..0deccc5 100644 --- a/NEWS +++ b/NEWS @@ -115,6 +115,9 @@ Version 2.26 C Library is GCC 4.9. Older GCC versions, and non-GNU compilers, can still be used to compile programs using the GNU C Library. +* The minimum GNU Binutils version that can be used to build this version of + the GNU C Library is Binutils 2.25. + Security related changes: * The DNS stub resolver limits the advertised UDP buffer size to 1200 bytes, diff --git a/configure b/configure index 97a2dad..320c196 100755 --- a/configure +++ b/configure @@ -4598,7 +4598,7 @@ $as_echo "$libc_cv_prog_ld_gnu" >&6; } gnu_ld=$libc_cv_prog_ld_gnu -# Accept binutils 2.22 or newer. +# Accept binutils 2.25 or newer. for ac_prog in $AS do # Extract the first word of "$ac_prog", so it can be a program name with args. @@ -4650,7 +4650,7 @@ $as_echo_n "checking version of $AS... " >&6; } ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* \([0-9]*\.[0-9.]*\).*$/\1/p'` case $ac_prog_version in '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; - 2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*) + 2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*) ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; @@ -4713,7 +4713,7 @@ $as_echo_n "checking version of $LD... " >&6; } ac_prog_version=`$LD --version 2>&1 | sed -n 's/^.*GNU ld.* \([0-9][0-9]*\.[0-9.]*\).*$/\1/p'` case $ac_prog_version in '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; - 2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*) + 2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*) ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; diff --git a/configure.ac b/configure.ac index 16e97d3..db1ea40 100644 --- a/configure.ac +++ b/configure.ac @@ -1071,14 +1071,14 @@ AC_PROG_LN_S LIBC_PROG_BINUTILS -# Accept binutils 2.22 or newer. +# Accept binutils 2.25 or newer. AC_CHECK_PROG_VER(AS, $AS, --version, [GNU assembler.* \([0-9]*\.[0-9.]*\)], - [2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], + [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], AS=: critic_missing="$critic_missing as") AC_CHECK_PROG_VER(LD, $LD, --version, [GNU ld.* \([0-9][0-9]*\.[0-9.]*\)], - [2.1[0-9][0-9]*|2.2[2-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], + [2.1[0-9][0-9]*|2.2[5-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], LD=: critic_missing="$critic_missing ld") # These programs are version sensitive. diff --git a/manual/install.texi b/manual/install.texi index 65174a8..f8442dd 100644 --- a/manual/install.texi +++ b/manual/install.texi @@ -489,7 +489,7 @@ You can use whatever compiler you like to compile programs that use Check the FAQ for any special compiler issues on particular platforms. @item -GNU @code{binutils} 2.22 or later +GNU @code{binutils} 2.25 or later You must use GNU @code{binutils} (as and ld) to build @theglibc{}. No other assembler or linker has the necessary functionality at the diff --git a/sysdeps/s390/configure b/sysdeps/s390/configure index 347ac28..d4a4a3d 100644 --- a/sysdeps/s390/configure +++ b/sysdeps/s390/configure @@ -4,71 +4,6 @@ $as_echo "#define PI_STATIC_AND_HIDDEN 1" >>confdefs.h -for ac_prog in $AS -do - # Extract the first word of "$ac_prog", so it can be a program name with args. -set dummy $ac_prog; ac_word=$2 -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5 -$as_echo_n "checking for $ac_word... " >&6; } -if ${ac_cv_prog_AS+:} false; then : - $as_echo_n "(cached) " >&6 -else - if test -n "$AS"; then - ac_cv_prog_AS="$AS" # Let the user override the test. -else -as_save_IFS=$IFS; IFS=$PATH_SEPARATOR -for as_dir in $PATH -do - IFS=$as_save_IFS - test -z "$as_dir" && as_dir=. - for ac_exec_ext in '' $ac_executable_extensions; do - if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then - ac_cv_prog_AS="$ac_prog" - $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 - break 2 - fi -done - done -IFS=$as_save_IFS - -fi -fi -AS=$ac_cv_prog_AS -if test -n "$AS"; then - { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AS" >&5 -$as_echo "$AS" >&6; } -else - { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 -$as_echo "no" >&6; } -fi - - - test -n "$AS" && break -done - -if test -z "$AS"; then - ac_verc_fail=yes -else - # Found it, now check the version. - { $as_echo "$as_me:${as_lineno-$LINENO}: checking version of $AS" >&5 -$as_echo_n "checking version of $AS... " >&6; } - ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* \([0-9]*\.[0-9.]*\).*$/\1/p'` - case $ac_prog_version in - '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; - 2.2[4-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*) - ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; - *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; - - esac - { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_prog_version" >&5 -$as_echo "$ac_prog_version" >&6; } -fi -if test $ac_verc_fail = yes; then - critic_missing="$critic_missing The program AS is required in version >= 2.24 for target S390." -fi - - - { $as_echo "$as_me:${as_lineno-$LINENO}: checking for __builtin_tbegin" >&5 $as_echo_n "checking for __builtin_tbegin... " >&6; } if ${libc_cv_gcc_builtin_tbegin+:} false; then : diff --git a/sysdeps/s390/configure.ac b/sysdeps/s390/configure.ac index 8a782e7..7d0b5ce 100644 --- a/sysdeps/s390/configure.ac +++ b/sysdeps/s390/configure.ac @@ -5,12 +5,6 @@ dnl It is always possible to access static and hidden symbols in an dnl position independent way. AC_DEFINE(PI_STATIC_AND_HIDDEN) -dnl Accept as 2.24 or newer. -AC_CHECK_PROG_VER(AS, $AS, --version, - [GNU assembler.* \([0-9]*\.[0-9.]*\)], - [2.2[4-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], critic_missing="$critic_missing The program AS is required in version >= 2.24 for target S390.") - - AC_CACHE_CHECK(for __builtin_tbegin, libc_cv_gcc_builtin_tbegin, [dnl cat > conftest.c <<\EOF #include <htmintrin.h> diff --git a/sysdeps/x86_64/configure b/sysdeps/x86_64/configure index 2d14c34..efef46b 100644 --- a/sysdeps/x86_64/configure +++ b/sysdeps/x86_64/configure @@ -1,70 +1,6 @@ # This file is generated from configure.ac by Autoconf. DO NOT EDIT! # Local configure fragment for sysdeps/x86_64. -for ac_prog in $AS -do - # Extract the first word of "$ac_prog", so it can be a program name with args. -set dummy $ac_prog; ac_word=$2 -{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for $ac_word" >&5 -$as_echo_n "checking for $ac_word... " >&6; } -if ${ac_cv_prog_AS+:} false; then : - $as_echo_n "(cached) " >&6 -else - if test -n "$AS"; then - ac_cv_prog_AS="$AS" # Let the user override the test. -else -as_save_IFS=$IFS; IFS=$PATH_SEPARATOR -for as_dir in $PATH -do - IFS=$as_save_IFS - test -z "$as_dir" && as_dir=. - for ac_exec_ext in '' $ac_executable_extensions; do - if as_fn_executable_p "$as_dir/$ac_word$ac_exec_ext"; then - ac_cv_prog_AS="$ac_prog" - $as_echo "$as_me:${as_lineno-$LINENO}: found $as_dir/$ac_word$ac_exec_ext" >&5 - break 2 - fi -done - done -IFS=$as_save_IFS - -fi -fi -AS=$ac_cv_prog_AS -if test -n "$AS"; then - { $as_echo "$as_me:${as_lineno-$LINENO}: result: $AS" >&5 -$as_echo "$AS" >&6; } -else - { $as_echo "$as_me:${as_lineno-$LINENO}: result: no" >&5 -$as_echo "no" >&6; } -fi - - - test -n "$AS" && break -done - -if test -z "$AS"; then - ac_verc_fail=yes -else - # Found it, now check the version. - { $as_echo "$as_me:${as_lineno-$LINENO}: checking version of $AS" >&5 -$as_echo_n "checking version of $AS... " >&6; } - ac_prog_version=`$AS --version 2>&1 | sed -n 's/^.*GNU assembler.* \([0-9]*\.[0-9.]*\).*$/\1/p'` - case $ac_prog_version in - '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; - 2.2[4-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*) - ac_prog_version="$ac_prog_version, ok"; ac_verc_fail=no;; - *) ac_prog_version="$ac_prog_version, bad"; ac_verc_fail=yes;; - - esac - { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_prog_version" >&5 -$as_echo "$ac_prog_version" >&6; } -fi -if test $ac_verc_fail = yes; then - critic_missing="$critic_missing The program AS is required in version >= 2.24 for target x86_64." -fi - - { $as_echo "$as_me:${as_lineno-$LINENO}: checking for AVX512DQ support in assembler" >&5 $as_echo_n "checking for AVX512DQ support in assembler... " >&6; } if ${libc_cv_asm_avx512dq+:} false; then : diff --git a/sysdeps/x86_64/configure.ac b/sysdeps/x86_64/configure.ac index 7d8aaaf..fa86e95 100644 --- a/sysdeps/x86_64/configure.ac +++ b/sysdeps/x86_64/configure.ac @@ -1,12 +1,6 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory. # Local configure fragment for sysdeps/x86_64. -dnl Accept as 2.24 or newer for AVX512 load and store. -AC_CHECK_PROG_VER(AS, $AS, --version, - [GNU assembler.* \([0-9]*\.[0-9.]*\)], - [2.2[4-9]*|2.[3-9][0-9]*|[3-9].*|[1-9][0-9]*], - critic_missing="$critic_missing The program AS is required in version >= 2.24 for target x86_64.") - dnl Check if asm supports AVX512DQ. AC_CACHE_CHECK(for AVX512DQ support in assembler, libc_cv_asm_avx512dq, [dnl cat > conftest.s <<\EOF