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

[Steven Munroe]

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.