Refine documentation of libm exceptions goals [committed]

[Joseph Myers]

On Wed, 18 Feb 2015, Rich Felker wrote:

> > > well, there are no precision requirements on not exactly-defined math
> > > functions, but with that interpretation an implementation which never
> > > raises underflow is also correct: it can claim that it exactly computed
> > > an incorrect result so there is no precision loss and thus no underflow
> > 
> > Yes.  This falls under the general implementation-defined accuracy of libm 
> > functions.
> 
> I think this is a stretch to say that implementation-defined accuracy
> allows an implementation to falsely report a result as exact when it's
> not. For all functions in the math library it's relatively trivial to

I see that as being potentially a < 1ulp error.  There is *never* any 
requirement (except for fma, sqrt, etc.) for "inexact" exceptions to be 
correct (in either direction), so this is just about whether there is a 
stricter requirement in the underflow case.  And C99 and C11 Annex F bind 
to IEEE 754-1985, which permits denormalization loss as an alternative to 
inexactness for when underflow is raised (and many of the cases where it's 
missed in practice correspond to cases of scaling down a normal result, 
where the scaling is exact - i.e., no denormalization loss).  (Whether 
libm functions not directly bound to IEEE operations are covered by the 
constraint that all operations raise underflow under the same conditions, 
so that they can't use "denormalization loss" where basic arithmetic 
operations use "inexact result", is doubtful.)

-- 
Joseph S. Myers
joseph@codesourcery.com