Re: [RFC] How to add vector math functions to Glibc

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 30 Sep 2014, Andrew Senkevich wrote:

> 2014-09-30 20:35 GMT+04:00 Joseph S. Myers <joseph@codesourcery.com>:
> > On Tue, 30 Sep 2014, Andrew Senkevich wrote:
> >
> >> diff --git a/configure.ac b/configure.ac
> >> index 82d0896..c5c1758 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -903,7 +903,7 @@ LIBC_PROG_BINUTILS
> >>  # Accept binutils 2.20 or newer.
> >>  AC_CHECK_PROG_VER(AS, $AS, --version,
> >>    [GNU assembler.* \([0-9]*\.[0-9.]*\)],
> >> -  [2.1[0-9][0-9]*|2.[2-9][0-9]*|[3-9].*|[1-9][0-9]*], AS=:
> >> critic_missing="$critic_missing as")
> >> +  [2.1[0-9][0-9]*|2.[2-9][2-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-9][0-9]*|[3-9].*|[1-9][0-9]*], LD=:
> >> critic_missing="$critic_missing ld")
> >
> > Any change to required versions needs to include an update to install.texi
> > (and the generated INSTALL file).  It should also be proposed in a
> > separate thread whose subject describes what is being proposed.
> 
> I thought it is already agreed in
> https://sourceware.org/ml/libc-alpha/2014-09/msg00586.html
> But if separate thread is required I can start it.

In general, patch submissions should be minimal (subject to bisectability) 
- if pieces can sensibly be separated out, they should be, and each piece 
should be given a meaningful subject (which will be the summary line of 
the git commit message) describing what that piece does.  It's entirely 
plausible there are people concerned about a change to build requirements 
who aren't concerned about vector functions.

> > Do you need to link libmvec against libm (and if so, I'd expect associated
> > Makefile rules, and maybe a Depend file to ensure the directories are
> > built in the right order)?
> 
> Libmvec contains calls to scalar version from libm, but not supposed
> to be used directly.
> Is it ok not to link libmvec against libm in this case?

No.  To have proper versioned undefined references, if a library A has an 
undefined reference to a function from another library B then A must be 
linked against B; otherwise you get an undefined reference without symbol 
version specified.

> Is it OK to add configure option enabled by default on x86_64 and
> disabled on unsupported architectures?

I think that would be appropriate.

> diff --git a/sysdeps/unix/sysv/linux/x86_64/64/libmvec.abilist
> b/sysdeps/unix/sysv/linux/x86_64/64/libmvec.abilist

Unless and until there is a reason for the set of symbols in this library 
to differ between -mx32 and -m64, I think the ABI baseline should go 
directly in sysdeps/unix/sysv/linux/x86_64/ rather than the 64/ 
subdirectory.

-- 
Joseph S. Myers
joseph@codesourcery.com