This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimum floating-point requirements


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 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.

The POWER long double format, including its peculiarities and
limitations, has existed for over 20 years. It has performed to the
satisfaction of a huge number of customers without this additional
conformance. No one has requested this additional conformance except
people who are concerned about conformance for conformance sake.

> 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.

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
appropriate action by the GLIBC community.

If the GLIBC community intends to start imposing its opinions on the
business decisions of companies, it is going to hurt its reputation
and acceptance in the long run.

Thanks, David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]