Re: [PATCH 3/8] float128: Add wrappers for IEEE functions.

[Joseph Myers <joseph at codesourcery dot com>]

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