Re: document the fact that "Known Maximum Errors" might not be maximal

[Joseph Myers <josmyers@redhat.com>]

On Fri, 16 Feb 2024, Vincent Lefevre wrote:

> BTW, the manual contains
> 
> fmaf	-	-	-	-	-
> fma	-	-	-	-	-
> fmal	-	-	-	-	-
> fmaf128	-	-	-	-	-
> fma_ldoublef	-	-	-	-	-
> fma_ldouble	-	-	-	-	-
> fma_ldoublel	-	-	-	-	-
> fma_ldoublef128	-	-	-	-	-
> 
> However, correct rounding is required for these functions.

IBM long double doesn't have such a thing as correct rounding, so we allow 
errors of up to 3ulp (the documented accuracy for IBM long double 
division) for functions expected to be correctly rounded for otehr 
formats.

> And I can't see any reference to f128, ldoublef, etc. in the manual
> except in this table.

See

@deftypefunx _FloatN fmafN (_Float@var{N} @var{x}, _Float@var{N} @var{y}, _Float@var{N} @var{z})
@deftypefunx _FloatNx fmafNx (_Float@var{N}x @var{x}, _Float@var{N}x @var{y}, _Float@var{N}x @var{z})

in the manual for fmaf128 (which should always be correctly rounded, since 
_Float128 is always IEEE binary128).

The "_ldouble" suffix is how libm-test-ulps indicates the argument type 
for narrowing functions that are parametrized by two types (that is, it's 
an implementation detail that ideally wouldn't appear in the manual at 
all).  IBM long double arguments (thus, float or double returns - 
functions {f,d}{add,sub,mul,div,sqrt,fma}l) is the only case where the 
narrowing functions should ever have results that are not correctly 
rounded.

-- 
Joseph S. Myers
josmyers@redhat.com