Repository navigation
Built by GCC 13 on AArch64 with the fp16 extension, crmvec's bfloat16
functions were wrong: f16check found 125,576 wrong results of 54,132,736.
GCC 13 loads a __bf16 constant with the FMOV instruction's half-precision
immediate, which encodes binary16, so 1.0 arrives as 0.0078125 (GCC bug
111867, fixed in GCC 14 and not backported). -march=native turns the fp16
extension on for most current Arm cores, and GCC 13 is Ubuntu 24.04's
default compiler. The bfloat16 files are now compiled with fp16 off under
GCC before 14, and the same build then matches MPFR on every input.
Packages built for the baseline architecture (armv8-a), as distributions
build them, were not affected.
On AArch64, make check now checks every half-precision and bfloat16 input
(f16check, against MPFR 4.2 or against the hash of outputs that matched
MPFR); until now only x86-64 ran it. The arm64 CI job also builds it with
the fp16 extension.
The CORE-MATH files are now those of its master branch at ea7a421 (they
were e78b460's): sin, exp, log, cbrtf16 and acos_bf16 changed upstream,
then cosh, cospi, exp, exp10, exp2, log10, log2, sinh, sinpi and tanpi.
Old against new, in all four rounding modes, the numeric results and
exception flags are the same on every input tried: 805,831,028 and
686,469,600 calls on x86-64 and aarch64, with every worst case CORE-MATH
lists for the updated binary64 functions.
sin of +inf, -inf and a NaN now returns +NaN, where 0.12.1 returned -NaN,
in both libraries and the libm preload, because CORE-MATH's sin does so
since its commit 040ee48. That changes three of the fast mode's results, so
its kernel version is now 2 (fast/bits-v2.txt; only sin differs from
version 1, and crmvec-run --fast --stamp records the version).
Otherwise the libraries give the same results as 0.12.1's.