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

[GT]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 28, 2019 6:51 PM, Tulio Magno Quites Machado Filho <tuliom@ascii.art.br> wrote:

> Joseph Myers joseph@codesourcery.com writes:
>
> > On Thu, 28 Feb 2019, Tulio Magno Quites Machado Filho wrote:
> >
> > > 1.  Guarantee the new code does not export neither a new ABI nor a new API.
> >
> > Right now it does export an ABI (meaning both the library symbols, and the
> > declarations in bits/math-vector.h that are expected to be interpreted by
> > a future compiler as meaning, in accordance with the ABI document that
> > needs to be written, that those library symbols are available -
> > bits/math-vector.h being installed regardless of whether the library is
> > built).
>
> Agreed. That has to be modified in the next patch submission.
>

Does the following procedure accomplish 'no change to API/ABI':

- Introduce a new preprocessor macro PPC64_VSX_DISABLE_LIBMVEC
- In sysdeps/powerpc/bits/math-vector.h, change:

# ifdef __DECL_SIMD_PPC64
#  undef __DECL_SIMD_cos
#  define __DECL_SIMD_cos __DECL_SIMD_PPC64

to:

+# if defined __DECL_SIMD_PPC64 && !(defined PPC64_VSX_DISABLE_LIBMVEC)
+#  undef __DECL_SIMD_cos
+#  define __DECL_SIMD_cos __DECL_SIMD_PPC64

- In sysdeps/powerpc/powerpc64/fpu/multiarch/vec_d_cos2_vsx.c, right
after definition of vector cosine function _ZGVbN2v_cos, add:

#if defined PPC64_VSX_DISABLE_LIBMVEC
libc_hidden_weak (_ZGVbN2v_cos)
#endif

- Control visibility of new vector math functions by calling configure with/out
CFLAGS="-g -O2 -DPPC64_VSX_DISABLE_LIBMVEC"

> > > 2.  A description on how to enable the code in order to test it without compiler
> > >     support. A public branch/repository is ideal.
> > >
> >
> > Sure, a branch is appropriate; the issues with lack of compiler support
> > are issues for having the support on master. Then, maybe a wiki page that
> > points to the glibc branch, the GCC branch (once available), the current
> > work on the ABI, etc., so people can find all the relevant pieces.
>
> Agreed.
>

1. So begin by cloning glibc to a new github project?
2. Send patches for review to libc-alpha prior to pushing any new commit
onto the branch on github.
3. When all reviewers accept changes in patch; rebase the working branch,
commit the changes and push to github.

Any changes needed to this workflow?


Thanks.
Bert.