This is the mail archive of the
mailing list for the GCC project.
Re: Fix IBM long double spurious overflows
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Date: Mon, 6 Jan 2014 10:41:50 -0500
- Subject: Re: Fix IBM long double spurious overflows
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401041314430 dot 23651 at digraph dot polyomino dot org dot uk>
On Sat, Jan 4, 2014 at 8:16 AM, Joseph S. Myers <email@example.com> wrote:
> This patch fixes various cases of spurious overflow exceptions in the
> IBM long double support code. The generic issue is that an initial
> approximation is computed by using the relevant arithmetic operation
> on the high parts of the operands - but this may overflow double in
> some cases where the final result is large but still a long way (up to
> around 2^53 ulp) from overflowing long double. For division overflow
> could occur not just from the initial a / c division but also from the
> subsequent multiplication of the result by c (in some cases where a is
> DBL_MAX, say), when the final result of the division need not be large
> at all.
> __gcc_qadd already tried to handle such overflow cases, but detected
> them by examining the result of the addition of high parts - which
> leaves a spurious overflow exception raised even if it returns the
> correct non-overflowing value. This patch instead checks the operands
> and does appropriate scaling, in all of __gcc_qadd, __gcc_qmul and
> __gcc_qdiv, to avoid spurious overflow exceptions arising as well as
> avoiding the bad results arising from such overflows.
> Tested with no regressions with cross to powerpc-linux-gnu (and also
> ran the glibc libm tests, which provide a rather more thorough test of
> floating-point arithmetic than the GCC testsuite; this patch fixes, at
> least, bad results from cbrtl (LDBL_MAX) that arose from the second
> division issue mentioned, as well as the specific cases shown in the
> tests added to the GCC testsuite). OK to commit?
Before we go farther down this path, IBM needs to internally decide on
the end goal and the amount of language / library conformance that
makes sense for the IBM long double format.