Re: [RESEND] [PATCH] PPC64: First in the series of patches implementing

[Joseph Myers <joseph at codesourcery dot com>]

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 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00184.html> against 
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 
available.)

-- 
Joseph S. Myers
joseph@codesourcery.com