Minimum floating-point requirements

[Joseph S. Myers]

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