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: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, David Edelsohn <dje dot gcc at gmail dot com>, <libc-alpha at sourceware dot org>
- Date: Mon, 17 Feb 2014 22:44:36 +0000
- Subject: Re: Minimum floating-point requirements
- Authentication-results: sourceware.org; auth=none
- References: <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> <Pine dot LNX dot 4 dot 64 dot 1402150136490 dot 31722 at digraph dot polyomino dot org dot uk> <CAGWvny=aJCdoQvC8q-dNvFdDNAqRCcZ7_adD=Sst8FDr0MN1Qg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402151656510 dot 6358 at digraph dot polyomino dot org dot uk> <20140216045946 dot GG184 at brightrain dot aerifal dot cx> <CAGWvny=9Jeippop9xuERzwgWL8+QbZiqQFhgxGNdAW0C=EnOLQ at mail dot gmail dot com> <20140216214623 dot GI184 at brightrain dot aerifal dot cx> <OF6C3CF9D0 dot 7DE26AD8-ON86257C82 dot 006D70FA-86257C82 dot 006EF9D5 at us dot ibm dot com>
On Mon, 17 Feb 2014, Steve Munroe wrote:
> Because I talk to a lot of customers and NOT ONE have asked for
> supporting long double in non default rounding modes. And I can't
> think of one customer that even wants to change the rounding mode.
I can't speak for your customers, but I've certainly seen customers report
issues with functions overflowing just before the correct start of the
overflowing range (the sort of case my patch for spurious overflows
addresses in the underlying arithmetic), and spurious / missing "inexact"
exceptions on e500 (the last platform I'd expect someone caring about the
finer points of floating point to be using). Maybe not for IBM long
double, but if they were using long double and PowerPC were the platform
they were using, reports of problems where would seem entirely plausible
to me.
Given bug reports, especially when there are multiple reports for related
issues, I prefer to fix the problems at source and increase test coverage
so that such issues in any libm function, for any floating-point type,
become visible and get resolved, rather than just fixing the one bug that
actually got reported when there are lots of related issues that are easy
to find.
> I would also like to understand how you plan to maintain the
> existing function and performance for customers who are happy
> with the status quo.
I have given plenty of suggestions, e.g.
<https://sourceware.org/ml/libc-alpha/2014-02/msg00469.html> and
<https://sourceware.org/ml/libc-alpha/2014-02/msg00497.html>, and am sure
you could think of more if desired.
--
Joseph S. Myers
joseph@codesourcery.com