public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Marcus Shawcroft <marcus.shawcroft@linaro.org>
To: joseph@codesourcery.com
Cc: libc-ports@sourceware.org
Subject: Re: [PATCH 1/2] AArch64 glibc port
Date: Mon, 05 Nov 2012 17:02:00 -0000	[thread overview]
Message-ID: <CABXK9nf1MgX90W-f2Ui2Wy=ooNP1G3_SfrcYtKh2daDTe_mPRw@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1211031735120.16168@digraph.polyomino.org.uk>

Thanks for the review, Ive looked into a couple of the FP issues and
would appreciate your thoughts on the following....

> While the optimized fma using fma instructions would no doubt fix those
> failures, they do suggest you have a bug in your sfp-machine.h - either it
> isn't setting INEXACT exceptions correctly from the addition, so
> fetestexcept fails to detect them, or it isn't handling underflow
> correctly on conversion to double, or both.  So if you investigate these
> failures before adding optimized fma, they may also solve some of your
> test-ldouble failures as well.

The first couple of failures we have in test-double.out are:
Failure: fma (min_value, min_value, +0) == +0: Exception "Underflow" not set
Failure: fma (min_value, min_value, -0) == +0: Exception "Underflow" not set

The addition cannot result in an UNDERFLOW, which suggests that
truncation is not correctly detecting  the UNDERFLOW.

Digging into the behaviour of trunctfdf2 (provided by libgcc) on the
value LDBL_MIN, I expected to see INEXACT and UNDERFLOW but only get
INEXACT.

The FP_TRUNC() macro detects the situation where the result exponent
is too small and zero's the result fractional bits, explicitly setting
the least significant working bit:

op-common.h:
1223               if (D##_e < 1 - _FP_FRACBITS_##dfs)
           \
1224                 {
           \
1225                   _FP_FRAC_SET_##swc(S, _FP_ZEROFRAC_##swc);
           \
1226                   _FP_FRAC_LOW_##swc(S) |= 1;
           \
1227                 }

Subsequently FP_ROUND() detects the non zero working bits and raises
INEXACT before applying 'round to nearest'. After rounding the working
bits are 0x5. The logic in _FP_PACKSEMIRAW() shifts out the working
bits leaving 0 in the fractional bits.  The detection of underflow
fails because the fractional bits are now all zero.

 145   _FP_FRAC_SRL_##wc(X, _FP_WORKBITS);                           \
 146   if (!_FP_EXP_NORMAL(fs, wc, X) && !_FP_FRAC_ZEROP_##wc(X))    \
 147     {                                                           \
 148       if (X##_e == 0)                                           \
 149         FP_SET_EXCEPTION(FP_EX_UNDERFLOW);                      \

The logic in FP_TRUNC highlighted above that sets the least
significant working bit makes the detection of underflow dependent on
rounding mode. Is this intentional?

Any insight into this welcome.

Thanks
/Marcus

  reply	other threads:[~2012-11-05 17:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CABXK9nfac4O=A0SMe_3FvTnqjpTDF0bDkd6inTBeSbK6DUtWOw@mail.gmail.com>
2012-10-03 22:11 ` Joseph S. Myers
2012-11-02 17:27   ` Marcus Shawcroft
2012-11-03 18:17     ` Joseph S. Myers
2012-11-05 17:02       ` Marcus Shawcroft [this message]
2012-11-05 18:06         ` Joseph S. Myers
2012-11-07 12:35           ` Marcus Shawcroft
2012-11-07 13:09             ` Joseph S. Myers
     [not found]       ` <CABXK9nfUuGCf2d8L4+ZnAMS+jdm_uMDcgTL619nbdHdpNEw_FQ@mail.gmail.com>
2012-11-07 15:16         ` Joseph S. Myers
2012-11-08  8:09         ` Fwd: " Marcus Shawcroft
2012-11-08 18:14           ` Joseph S. Myers
2012-11-08 21:26             ` Richard Henderson
2012-11-08 23:13               ` Joseph S. Myers
2012-11-09 18:07             ` Marcus Shawcroft
2012-11-09 19:35               ` Andreas Jaeger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABXK9nf1MgX90W-f2Ui2Wy=ooNP1G3_SfrcYtKh2daDTe_mPRw@mail.gmail.com' \
    --to=marcus.shawcroft@linaro.org \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).