This is the mail archive of the
mailing list for the glibc project.
Re: [RESEND] [PATCH] PPC64: First in the series of patches implementing
- From: Tulio Magno Quites Machado Filho <tuliom at ascii dot art dot br>
- To: Joseph Myers <joseph at codesourcery dot com>, David Edelsohn <dje dot gcc at gmail dot com>
- Cc: GT <tnggil at protonmail dot com>, GNU C Library <libc-alpha at sourceware dot org>, William J. Schmidt <wschmidt at linux dot ibm dot com>, Gabriel F. T. Gomes <gabriel at inconstante dot eti dot br>
- Date: Thu, 28 Feb 2019 15:00:24 -0300
- Subject: Re: [RESEND] [PATCH] PPC64: First in the series of patches implementing
- References: <CAGWvnykktWuDVLrMrOiLrGV9aOUUQNd8Bf1FiiWbQ_G-aXJyvQ@mail.gmail.com> <alpine.DEB.email@example.com>
Joseph Myers <firstname.lastname@example.org> writes:
> On Thu, 28 Feb 2019, David Edelsohn wrote:
>> Please stop creating an artificial chicken-and-egg problem. GCC does
> It's not artificial. It's about verifying that the glibc changes actually
> work as intended - in an area where the x86_64 patches, as originally
> committed, *didn't* work as intended (the sincos ABI problem), for the
> lack of such testing (so demonstrating that more testing is needed for
> future libmvec architectures).
> Right now, we have explicit statements from Tulio that the ABI *cannot* be
> confirmed to be as desired, which makes it particularly clear that
> integrating these patches would be premature.
I do not fully agree with this statement.
We cannot indeed set the ABI right now without answering the questions that
have already been raised.
However, I do believe this patch can be merged if it's changed to meet
community standards and if the code is not enabled or even built until we have
a final decision on the ABI (and GCC implementation), i.e. it must not export
a new ABI or API yet.
The entire process for enabling libmvec and GCC vector support is a long
process and I think it isn't ideal to delay all the patches until a point in
time where everything is working.
IMHO, we can:
1. Guarantee the new code does not export neither a new ABI nor a new API.
2. A description on how to enable the code in order to test it without compiler
support. A public branch/repository is ideal.
3. Review the patch in order to guarantee it does match the community
Meanwhile, I'll be working on the ABI drafts and I'm going to move forward the
ABI discussion that we started.
>> not need to implement the vector functionality before it can be merged
>> into GLIBC. One project needs to go first. An implementation in
>> GLIBC that will be leveraged by a future release of GCC is fine.
>> Because of the long pipeline for GLIBC to propagate into Linux
>> distributions, an early GLIBC implementation is very appropriate.
> The glibc freeze for 2.30 starts on 1 July. GCC 9 probably branches in
> late April.
As I said earlier: developing the entire support for all of this will likely