This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/8] float128: Add wrappers for IEEE functions.
- From: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "Gabriel F. T. Gomes" <gftg at linux dot vnet dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Mon, 05 Dec 2016 20:39:09 -0600
- Subject: Re: [PATCH 3/8] float128: Add wrappers for IEEE functions.
- Authentication-results: sourceware.org; auth=none
- References: <1478716859-3246-1-git-send-email-gftg@linux.vnet.ibm.com> <1478716859-3246-4-git-send-email-gftg@linux.vnet.ibm.com> <alpine.DEB.2.20.1611092132390.6428@digraph.polyomino.org.uk> <20161205144754.4c0c7c13@keller.br.ibm.com> <alpine.DEB.2.20.1612051829010.19059@digraph.polyomino.org.uk> <1480978305.13834.14.camel@oc7878010663> <alpine.DEB.2.20.1612060000430.15680@digraph.polyomino.org.uk>
- Reply-to: munroesj at linux dot vnet dot ibm dot com
On Tue, 2016-12-06 at 00:30 +0000, Joseph Myers wrote:
> On Mon, 5 Dec 2016, Steven Munroe wrote:
>
> > Are these changes really necessary at this time?
>
> The question is what is the right, most maintainable way to add support
> for a new floating-point format and associated type. Given that support
> for further formats / types may well be added in future (_Float16 being
> the most obvious possibility; WG14 has also expressed support for
> considering adding short float to C2x, which would likely alias _Float16
> functions when not aliasing float ones), minimising the number of places
> where something needs repeating for each new type is clearly an important
> consideration.
>
I am not disagreeing with the goal, but I am questioning the priorities.
> Since we've also desired for a long time to obsolete support for
> _LIB_VERSION and matherr, avoiding support for those in new interfaces is
> also clearly desirable - any ABI added needs to be supported long-term, so
> we need to be careful that it's the right ABI. This indicates using
> new-style wrappers for the new types, while the previous point indicates
> making those wrappers type-generic. Then, the question is simply how to
> use the type-generic wrappers for new types without affecting binary
> compatibility for the old types, which is the subject of the present
> discussion.
>
> Note that I'm not saying the whole deprecation needs to go in at this
> point. Just that the desire for a future deprecation provides useful
> guidance on the arrangements for the new wrappers.
>
Good then we will only do the minimum to complete the current patch set.
As you suggest.
> Since I was warning over a year ago about the complexity of supporting a
> new type (I expected 50 to 100 patches), and included matherr / wrappers
> in the issues to consider, I don't think any of this should be a surprise.
> I think all the development so far that Paul and others have worked on has
> been perfectly consistent with what I advised - adding support for the new
> type is perfectly feasible, substantial progress has been made, various
> design details have changed over time but the overall outline is as
> expected, the complexity of the changes means it's usual for a patch
> series to require several reviews and revisions and possibly design
> changes before it's ready to go in (but the numbers of revisions involved
> are small compared to many I've seen in the Linux kernel context where a
> patch series can have dozens of revisions and take years to get in).
>
That is exactly what I am worried about.
Perfection is the enemy of good.