about summary refs log tree commit diff
path: root/rt/tst-mqueue3.c
diff options
context:
space:
mode:
authorJoseph Myers <joseph@codesourcery.com>2015-02-17 23:41:27 +0000
committerJoseph Myers <joseph@codesourcery.com>2015-02-17 23:41:27 +0000
commit18a218b74c6b421d37316371d892a2f3b752eb93 (patch)
tree2acf78a90b03745149557d63ecb4e5c45f2f0ccd /rt/tst-mqueue3.c
parente72ad0ef31a5be84c43cc826db97b8c74881faf4 (diff)
downloadglibc-18a218b74c6b421d37316371d892a2f3b752eb93.tar.gz
glibc-18a218b74c6b421d37316371d892a2f3b752eb93.tar.xz
glibc-18a218b74c6b421d37316371d892a2f3b752eb93.zip
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.
Diffstat (limited to 'rt/tst-mqueue3.c')
0 files changed, 0 insertions, 0 deletions