From: Joseph Myers <joseph@codesourcery.com>
To: Steven Munroe <munroesj@linux.vnet.ibm.com>
Cc: "Gabriel F. T. Gomes" <gftg@linux.vnet.ibm.com>,
<libc-alpha@sourceware.org>
Subject: Re: [PATCH 3/8] float128: Add wrappers for IEEE functions.
Date: Tue, 06 Dec 2016 00:31:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1612060000430.15680@digraph.polyomino.org.uk> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2016-12-06 0:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 18:41 [PATCH 0/8] More float128 declarations Gabriel F. T. Gomes
2016-11-09 18:41 ` [PATCH 1/8] ldbl-128: Use mathx_hidden_def inplace of hidden_def Gabriel F. T. Gomes
2016-11-09 18:41 ` [PATCH 6/8] float128: Expose _Float128 finite math functions Gabriel F. T. Gomes
2016-11-09 22:06 ` Joseph Myers
2017-03-03 20:17 ` Gabriel F. T. Gomes
2017-03-03 20:50 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 3/8] float128: Add wrappers for IEEE functions Gabriel F. T. Gomes
2016-11-09 21:38 ` Joseph Myers
2016-12-05 16:48 ` Gabriel F. T. Gomes
2016-12-05 18:51 ` Joseph Myers
2016-12-05 22:52 ` Steven Munroe
2016-12-06 0:31 ` Joseph Myers [this message]
2016-12-06 2:39 ` Steven Munroe
2016-12-07 19:36 ` Gabriel F. T. Gomes
2016-12-07 21:47 ` Joseph Myers
2016-12-09 21:24 ` Gabriel F. T. Gomes
2016-12-14 0:47 ` Joseph Myers
2016-12-14 13:36 ` Gabriel F. T. Gomes
2016-12-14 14:33 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 4/8] Add support for testing __STDC_WANT_IEC_60559_TYPES_EXT__ Gabriel F. T. Gomes
2016-11-09 21:42 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 5/8] float128: Add public _Float128 declarations to libm Gabriel F. T. Gomes
2016-11-09 22:04 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 2/8] float128: Add _Float128 make bits " Gabriel F. T. Gomes
2016-12-09 21:23 ` Tulio Magno Quites Machado Filho
2016-12-12 22:49 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 8/8] float128: Add wrappers to override ldbl-128 as float128 Gabriel F. T. Gomes
2016-11-09 22:13 ` Joseph Myers
2016-11-09 18:41 ` [PATCH 7/8] float128: Add private _Float128 declarations for libm Gabriel F. T. Gomes
2016-11-09 22:08 ` Joseph Myers
2016-11-10 22:13 ` Joseph Myers
2016-11-09 21:31 ` [PATCH 0/8] More float128 declarations Joseph Myers
2016-11-09 23:52 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1612060000430.15680@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gftg@linux.vnet.ibm.com \
--cc=libc-alpha@sourceware.org \
--cc=munroesj@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).