This is the mail archive of the
mailing list for the glibc project.
Re: [RESEND] [PATCH] PPC64: First in the series of patches implementing
On Thu, 28 Feb 2019, David Edelsohn wrote:
> It depends if the patches create any new, public symbols, i.e., if they are
> enabled by default. I'll allow Tulio to state his desires instead of applying
> biases to other people's statements.
The patches create new public symbols in a new library. My understanding
of the latest patch version is that it doesn't build the library by
default, but that introduces its own problems.
bits/math-vector.h doesn't depend on whether the library was built (after
all, it's meant to be shared between multilibs, including 32-bit ones that
can't build the library). So if you don't build by default, that means
you, by default, get bits/math-vector.h installed that declares the
functions to be available when the library with them isn't actually
available. I.e., you get bits/math-vector.h installed that will result in
link-time failures when compiling using a future compiler release that
supports the new ABIs - which is an unhelpful default.
That strongly indicates the appropriate default *is* to build the library
by default (cf. Rich Felker's argument
libmvec being optional at all, on platforms that support it).
(In the x86_64 discussions I was very careful to make sure the ABI was
defined so that given pragmas meant a particular, fixed set of function
variants would be available - that it would not be valid to reinterpret
those pragmas in future as also meaning e.g. an AVX1024 function variant
was available, because that would result in the same problem with old
libraries and headers and new compilers. Thus, if AVX1024 vector
functions are added in future, they will need a different, new pragma for
bits/math-vector.h to tell the compiler that those functions are
Joseph S. Myers