Minimum floating-point requirements

[Joseph S. Myers]

On Sat, 15 Feb 2014, David Edelsohn wrote:

> On Fri, Feb 14, 2014 at 8:57 PM, Joseph S. Myers
> <joseph@codesourcery.com> wrote:
> 
> > I want to achieve something that accords with previously agreed consensus
> > on libm function goals - consensus that already takes account of IBM long
> > double peculiarities and allows more laxity for certain functions in
> > certain cases for IBM long double than for other formats.  We have already
> > considered the trade-offs and reached conclusions that we believe
> > represent reasonable default libm function behavior in the absence of
> > options being used to select different trade-offs.
> 
> Who is "we"?

The glibc developers who have considered questions of whether particular 
patches improving libm functions in some way, or increasing testsuite 
coverage, are appropriate, discussed the trade-offs and agreed on the text 
now in the manual about accuracy goals for results and exceptions.

> The POWER long double format, including its peculiarities and
> limitations, has existed for over 20 years. It has performed to the

And in that time, the world in which glibc operates has changed.  It was 
once a C90 library and now supports C11; limitations that were appropriate 
20 years ago are no longer appropriate.  glibc has moved away from the 
position under previous developers of not supporting functions in 
non-default rounding modes; we have fixed functions such as the default 
versions used for double on many platforms to work in all rounding modes, 
and removed x86 functions that had large errors, and then, where people 
have been concerned about performance consequences, they have worked to 
improve the performance of the functions while keeping the correctness 
(and there is still plenty of scope for further such performance 
improvements).

> Your previous message made clear that the request of additional
> functions is a prelude to imposing the new semantics as the defacto
> default because other fundamental libraries would be compiled in that
> mode, thereby imposing it on the entire ecosystem. That is not an

I am not trying to impose this mode on non-glibc libraries and do not plan 
to propose changes to those libraries to use this mode, although I have 
views about what would be correct for them - I think that's up to the 
developers of those libraries.

There are many different ways in which people can use glibc and GCC, and 
breadth in supporting such ways in a strength of the GNU system.  I'm 
trying to increase that breadth in GCC in a way I find useful.  Much free 
software development is about itch-scratching; just because your customers 
don't have a use for this breadth doesn't mean it's bad for GCC.  I would 
welcome breadth in glibc in terms of additional non-default libm function 
variants, such as __*_fast functions used with -ffast-math (which would be 
built in the existing default mode, not the new non-default mode), if 
people interested in those wish to contribute them.

But I think this is a matter of imposing a decision about the PowerPC 
"ecosystem" (see <https://www.gnu.org/philosophy/words-to-avoid.html>) on 
glibc as much as imposing anything from glibc on anything else.  And the 
ultimate question is about the GNU system rather than that "ecosystem".

-- 
Joseph S. Myers
joseph@codesourcery.com