[PATCH 0/3] Fix powf inaccuracies up to ~169 ULP reported by Paul Zimmermann

[brian.inglis@systematicsw.ab.ca]

On 2024-09-12 01:20, Paul Zimmermann wrote:
>         Hi Brian,
> 
>>> $ gcc test_printf.c /localdisk/zimmerma/newlib-4.4.0.20231231/build/x86_64/newlib/libm.a
>>> $ ./a.out
>>> x=0.9694811147877118 upward:0.969481
>>>
>>> Is that a known issue?
>>
>> Is that not only a requirement of IEEE arithmetic operations?
>> Is that also an expected requirement of *printf?
> 
> the C standard [1] writes on page 511:
> 
> 15 The binding for the convertFormat operation applies to all conversions among IEC 60559 formats.
> Therefore, for implementations that conform to Annex F, conversions between decimal floating types
> and standard floating types with IEC 60559 formats are correctly rounded and raise floating-point
> exceptions as specified in IEC 60559.

Those are references to IEC/IEEE 60559 BFP binary and DFP decimal FPU formats in 
F.3 Operations.

> [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

N3301 is C203Y WD with final C2024 text plus a few new changes: F3. Operations 
para.15 p.534.

GCC float.h sets FLT_ROUNDS 1 and CR_DECIMAL_DIG to UINTMAX_MAX, and says it 
follows *C99* Annex F except where it says results depend on the standard 
library implementation.

The newlib and glibc standard I/O libraries say only correctly rounded, and some 
limits on correctly rounded digits, but say nothing about Annex F or IEC/IEEE 
60559.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry