This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Minimum floating-point requirements
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, Steve Munroe <sjmunroe at us dot ibm dot com>
- Date: Wed, 29 Jan 2014 17:57:56 -0500
- Subject: Re: Minimum floating-point requirements
- Authentication-results: sourceware.org; auth=none
>>>>> Joseph Myers wrote:
> I propose the following as minimum requirements on the underlying
> floating-point arithmetic used in glibc (libc and libm) (this is about
> float / double / long double rather than any other types; in particular,
> complex multiplication / division in libgcc follows lower standards and is
> generally avoided in glibc):
>
> * No support for new formats not following IEEE semantics should be added.
>
> * As a consequence of the above, we should seek FSF approval to copy the
> IBM long double support from libgcc into glibc, under LGPLv2.1+, so that
> it can be adapted to meet the above standards.
Joseph,
As we discussed on the GCC Mailing List, I appreciate your desire for
all GLIBC targets and ports to conform to relevant standards (IEEE,
ISO C, etc.), but I think it is a very bad precedent to use standards
conformance and community rules to override port maintainers in
port-specific decisions. GLIBC should strive to be welcoming of all
ports and all architectures and allow port developers and maintainers
the freedom to create the best port possible. A port that better
serves its user community and user priorities will attract more users
and expand the usage of GLIBC.
If GLIBC becomes overly strict and dictatorial under the guise of
conformity and policy, it will drive new developers, new ports and new
innovation away, ultimately undermining the community and project. One
can push more of the responsibility and work to maintain
non-conforming ports onto port-specific maintainers to discourage it,
but it should not be the role of GLIBC to impose its will on
ABI-specific decisions of a target.
Every architecture and ABI has things that the designers wish had been
done differently using 20/20 hindsight, but we live in the imperfect,
real world with compromise.
Thanks, David