This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Joseph Myers <> 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
take longer.

Tulio Magno

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]