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 01:57:24 +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>
On Fri, 14 Feb 2014, David Edelsohn wrote:
> This is the exact issue. You want to impose something that is
> convenient for you. You have decided that the ultimate goal should be
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.
> cleanliness and conformance. And you want to use language standards,
> library standards and project rules to impose your vision on the
> PowerPC port.
The PowerPC port is not just for recent POWER server hardware and whatever
applications thereon care about performance of certain long double
operations but not about accuracy and exceptions in cases where the
present functions are defective. I'm thinking more in terms of embedded
and general-purpose GNU/Linux distributions that support a wide range of
processors and where consistency between different architectures is
important. And I consider consistency between different architectures to
be one of the great strengths of the GNU system as a whole.
My position is, and I think the reflects general consensus among those
working on glibc libm:
* Contributions of functions tuned to particular requirements, and
selected based on compiler options, are welcome. See
<https://sourceware.org/glibc/wiki/libm> for one possibility, with links
to more detailed discussions.
* Default goals that follow consensus about a reasonable set of trade-offs
are documented in the glibc manual. Failures to meet those goals should
be fixed at source - in glibc if the issue is in glibc, in libgcc if the
issue is in libgcc, in the kernel if kernel emulation is the problem.
* Expected failures in such cases should be purely temporary until the bug
is fixed, and not added at all where fixing the bug is less work than
adding the expected failures (as it is in this case).
* Blocking a fix for a failure to meet the agreed goals on performance
grounds is premature optimization; optimization should be subject to
correctness. We have made plenty of changes on that basis before.
Thus, I am asking for the powerpc GCC maintainers to accept additional
function variants in libgcc that are appropriate for glibc's agreed
default trade-offs. This is a matter of GNU project principles of
cooperation between GNU projects in building the GNU system. I will refer
this matter to the GCC SC now, as something engaging with GNU project
principles.
--
Joseph S. Myers
joseph@codesourcery.com