This is the mail archive of the glibc-cvs@sourceware.org mailing list for the glibc 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]

GNU C Library master sources branch master updated. glibc-2.21-91-g18a218b


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  18a218b74c6b421d37316371d892a2f3b752eb93 (commit)
      from  e72ad0ef31a5be84c43cc826db97b8c74881faf4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=18a218b74c6b421d37316371d892a2f3b752eb93

commit 18a218b74c6b421d37316371d892a2f3b752eb93
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Tue Feb 17 23:41:27 2015 +0000

    Refine documentation of libm exceptions goals.
    
    This patch refines the math.texi documentation of the goals for when
    libm function raise the inexact and underflow exceptions.  The
    previous text was problematic in some cases around the underflow
    threshold.
    
    * Strictly, it would have meant that if the mathematical result of pow
      was very slightly below DBL_MIN, for example, it was required to
      raise the underflow exception; although normally a few ulps error
      would be OK, if that error meant the computed value was slightly
      above DBL_MIN it would fail the previously described underflow
      exception goal.
    
    * Similarly, strict IEEE semantics would imply that sin (DBL_MIN), in
      round-to-nearest mode, underflows on before-rounding but not
      after-rounding architectures, while returning DBL_MIN; the previous
      wording would have required an underflow exception, so preventing
      checks for a result with absolute value below DBL_MIN from being
      sufficient checks to determine whether the exception is required.
      (Under the previous wording, checks for a result with absolute value
      <= DBL_MIN wouldn't have been sufficient either, because in
      FE_TOWARDZERO mode a result of DBL_MIN definitely does not result
      from an underflowing infinite-precision result.)
    
    * The previous wording about rounding infinite-precision values could
      be taken to mean all exceptions including "inexact" must be
      consistent with some such value.  That would mean that a result of
      DBL_MIN in FE_UPWARD mode with "inexact" raised must also have
      "underflow" raised on before-rounding architectures.  Again, that
      would cause problems for computing a result (possibly with spurious
      "inexact" exceptions) and then using a rounding-mode-independent
      test for results with absolute value below DBL_MIN to determine
      whether an underflow exception must be forced in case the underflows
      from intermediate computations happened to be exact.
    
    By refining the documentation, this patch avoids stating goals for
    accuracy close to the underflow threshold that were stricter than
    applied anywhere else, and allows the implementation strategy of:
    compute a result within a few ulps, taking care to avoid underflows in
    intermediate computations, then force an underflow exception if that
    result was subnormal.  Only fully-defined functions such as fma need
    to take greater care about the exact underflow threshold (including
    its dependence on whether the architecture is before-rounding or
    after-rounding, and on the rounding mode on after-rounding
    architectures).
    
    (If the rounding mode is changed as part of the computation, it's
    still necessary to ensure that not just intermediate computations, but
    the final computation of the result to be returned, do not raise
    underflow if that result is the least normal value and underflow would
    be inconsistent with the original rounding mode.  Since such code can
    readily discard exceptions as part of saving and restoring the
    rounding mode - SET_RESTORE_ROUND_NOEX etc. - I don't think that
    should be a problem in practice.)
    
    	* manual/math.texi (Errors in Math Functions): Clarify goals
    	regarding inexact and underflow exceptions.

diff --git a/ChangeLog b/ChangeLog
index c44ce0d..8471285 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2015-02-17  Joseph Myers  <joseph@codesourcery.com>
+
+	* manual/math.texi (Errors in Math Functions): Clarify goals
+	regarding inexact and underflow exceptions.
+
 2015-02-17  Steve Ellcey  <sellcey@imgtec.com>
 
 	* sysdeps/mips/memcpy.S: Move R6 PREFETCH_STORE_HINT check.
diff --git a/manual/math.texi b/manual/math.texi
index 206021c..72f3fda 100644
--- a/manual/math.texi
+++ b/manual/math.texi
@@ -1313,7 +1313,9 @@ exact value passed as the input.  Exceptions are raised appropriately
 for this value and in accordance with IEEE 754 / ISO C / POSIX
 semantics, and it is then rounded according to the current rounding
 direction to the result that is returned to the user.  @code{errno}
-may also be set (@pxref{Math Error Reporting}).
+may also be set (@pxref{Math Error Reporting}).  (The ``inexact''
+exception may be raised, or not raised, even if this is inconsistent
+with the infinite-precision value.)
 
 @item
 For the IBM @code{long double} format, as used on PowerPC GNU/Linux,
@@ -1344,11 +1346,16 @@ subnormal (in each case, with the correct sign), according to the
 current rounding direction and with the underflow exception raised.
 
 @item
-Where the mathematical result underflows and is not exactly
-representable as a floating-point value, the underflow exception is
-raised (so there may be spurious underflow exceptions in cases where
-the underflowing result is exact, but not missing underflow exceptions
-in cases where it is inexact).
+Where the mathematical result underflows (before rounding) and is not
+exactly representable as a floating-point value, the function does not
+behave as if the computed infinite-precision result is an exact value
+in the subnormal range.  This means that the underflow exception is
+raised other than possibly for cases where the mathematical result is
+very close to the underflow threshold and the function behaves as if
+it computes an infinite-precision result that does not underflow.  (So
+there may be spurious underflow exceptions in cases where the
+underflowing result is exact, but not missing underflow exceptions in
+cases where it is inexact.)
 
 @item
 @Theglibc{} does not aim for functions to satisfy other properties of

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog        |    5 +++++
 manual/math.texi |   19 +++++++++++++------
 2 files changed, 18 insertions(+), 6 deletions(-)


hooks/post-receive
-- 
GNU C Library master sources


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