This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: Fix IBM long double spurious overflows


On Sat, Jan 4, 2014 at 8:16 AM, Joseph S. Myers <joseph@codesourcery.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.

Thanks, David


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