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

[GT <tnggil at protonmail dot com>]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, March 1, 2019 10:09 PM, Joseph Myers <joseph@codesourcery.com> wrote:

> On Fri, 1 Mar 2019, GT wrote:
>
> > 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:
>
> That name is in the user's namespace, so it should not be tested in any
> installed header.
>

The objection here being that the macro name is missing a double-underscore
prefix? Or, because the patches are destined for a branch, there is no longer
need for the macro at all?


> If you're not changing the API/ABI, I don't think the patches belong in
> glibc master (as opposed to on some branch, and on the branch you can just
> enable the features by default).
>

It's become unclear to me what it will take for the double-precision cosine
patch to be accepted, allowing me to move on to the single-precision cosine.

1. With no GCC support imminent - weeks away at a minimum - is testing done
by 'make check' all that is required for patch acceptance into the branch?

2. Someone with access has to create the branch. Who/when and what is the
name of said branch?

3. Meanwhile, I finish making changes asked for from the last submission to
libc-alpha. Then wait until branch is created before sending new patch?
Presumably because I will first have to clone that branch and commits will be
against its HEAD?