This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Minimum floating-point requirements
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: Steve Munroe <sjmunroe at us dot ibm dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, <libc-alpha at sourceware dot org>
- Date: Sat, 15 Feb 2014 17:21:29 +0000
- Subject: Re: Minimum floating-point requirements
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnym4yN=7rLrm0RRtNN++T=xwx8r3MUKJOfz4r+H=Z9zd7Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401300038120 dot 24633 at digraph dot polyomino dot org dot uk> <OF9FA4A0A3 dot 0CD33B43-ON86257C70 dot 0073531F-86257C70 dot 0073A4BB at us dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1401302108080 dot 12540 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1402072347200 dot 12232 at digraph dot polyomino dot org dot uk> <OF54854818 dot C108092B-ON86257C7B dot 0063B8C0-86257C7B dot 006B6B53 at us dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1402102231400 dot 26591 at digraph dot polyomino dot org dot uk> <CAGWvnyn-Cj4Mw4efQTs2MYFHhknyskAEznEqpGeYnb9rY3X4hg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402150136490 dot 31722 at digraph dot polyomino dot org dot uk> <CAGWvny=aJCdoQvC8q-dNvFdDNAqRCcZ7_adD=Sst8FDr0MN1Qg at mail dot gmail dot com>
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