This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Build failure on MIPS (strtorx.c) [Patch attached]
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: <newlib at sourceware dot org>
- Cc: Steve Ellcey <sellcey at imgtec dot com>, Jeff Johnston <jjohnstn at redhat dot com>
- Date: Wed, 27 Jan 2016 01:14:38 +0000
- Subject: Re: Build failure on MIPS (strtorx.c) [Patch attached]
- Authentication-results: sourceware.org; auth=none
- References: <6b3cf942-89f5-43f0-bb0b-33a8f1c8515a at BAMAIL02 dot ba dot imgtec dot org> <alpine dot DEB dot 2 dot 00 dot 1511241814220 dot 6915 at tp dot orcam dot me dot uk> <1448391595 dot 26738 dot 7 dot camel at ubuntu-sellcey> <2130974635 dot 22651399 dot 1448401853772 dot JavaMail dot zimbra at redhat dot com> <1448402454 dot 26738 dot 8 dot camel at ubuntu-sellcey> <20151126091605 dot GA21977 at calimero dot vinschen dot de>
On Thu, 26 Nov 2015, Corinna Vinschen wrote:
> However, the *QNAN* values to support long double on MIPS are available
> in FreeBSD. Wouldn't it make sense to support long double on MIPS, too?
GCC has quad float support available for 64-bit MIPS targets, so yes,
support for 128-bit long double would be possible.
Question however is which of the two potential formats to choose: either
the IEEE quad format, only supported as soft-float with MIPS hardware, or
the IBM extended precision format, which can be handled with MIPS hardware
and was used by IRIX. Both are supported by GCC and both have advantages
and drawbacks. So I think the decision to support either or both will
best be left to such a time when there is actual interest, at which point
encoding the NaN patterns will likely be the least of a problem.
FWIW,
Maciej