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: Joseph Myers <joseph at codesourcery dot com>
- To: Steven Munroe <munroesj at linux dot vnet dot ibm dot com>
- Cc: "Gabriel F. T. Gomes" <gftg at linux dot vnet dot ibm dot com>, <libc-alpha at sourceware dot org>
- Date: Tue, 6 Dec 2016 00:30:53 +0000
- 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>
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.
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.
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).
--
Joseph S. Myers
joseph@codesourcery.com