changelog

crmvec (0.12.2) unstable; urgency=medium

  * The bfloat16 functions were wrong (125,576 of 54,132,736 results in
    f16check) when built by GCC 13 on AArch64 with the fp16 extension, as
    -march=native gives on most current Arm cores: GCC 13 loads a __bf16
    constant as binary16 (GCC bug 111867, fixed in GCC 14). bf16/*.c are now
    compiled with fp16 off under GCC before 14. Packages built for the
    baseline architecture were not affected.
  * On aarch64, make check now builds f16check against the aarch64 library and
    checks every half and bfloat16 input, against MPFR 4.2 or the recorded
    output hash.
  * The CORE-MATH files are those of its master branch at ea7a421 (from
    e78b460): old against new, the same numeric results and exception flags on
    805,831,028 and 686,469,600 calls on x86-64 and aarch64 (any two NaNs
    counted equal), every worst case of the updated binary64 functions
    included.
  * sin of +inf, -inf and a NaN now returns +NaN, where 0.12.1 returned -NaN,
    in both libraries and the libm preload: CORE-MATH's sin does so since
    040ee48. The fast mode's kernel version is therefore 2 (fast/bits-v2.txt):
    only sin's hash differs from version 1.
  * The libraries' results are otherwise the same as 0.12.1's.

 -- anun333 <anun333@posteo.net>  Mon, 12 Oct 2026 18:17:54 -0500

crmvec (0.12.1) unstable; urgency=medium

  * Building needs gcc 13 or newer on x86-64 (__bf16; _Float16 and
    __builtin_convertvector need 12 and 9), and make now checks before the
    first object and names the compiler to use on each older release.
  * crmvec.spec builds with gcc-toolset-14 on RHEL 8 and 9 and with gcc13 on
    openSUSE Leap 15. Its packages build, pass make check, install and run
    on AlmaLinux 8, 9 and 10, openSUSE Leap 15.6 and 16.0 and Debian 13, as
    on Fedora and Ubuntu 24.04.
  * The checks find which libmvec.so.1 they loaded by asking the loader: on
    openSUSE, whose gcc builds non-PIE executables, mpfrcheck came out VOID.
  * f16check builds without MPFR 4.2 and then compares its output hash with
    f16check-hash.txt, recorded from builds that matched MPFR; mpfrcheck and
    f16check link -ldl, for glibc before 2.34.
  * The libraries are the same as 0.12.0's.

 -- anun333 <anun333@posteo.net>  Thu, 08 Oct 2026 17:52:08 -0500

crmvec (0.12.0) unstable; urgency=medium

  * The fast mode's AVX2 entry points are IFUNCs, bound at load time to each
    kernel's own entry, which holds the rounding-mode test: a median 1.02
    times glibc 2.41's libmvec time on an EPYC 7773X (from 1.09), floats
    1.00 (from 1.17), and the same results as before on every input.
  * The fast mode's results are versioned: fast/fastbits and
    fast/bits-v1.txt record kernel version 1, unchanged since 0.10.0, and
    make check-fast fails on any change; a release that changes a result
    bumps the version (docs/fast-mode.md). fast/mode-check.sh checks its
    fallback outside round-to-nearest.
  * crmvec-stamp records a crmvec-run --fast run as the fast mode, not
    correctly rounded, with its kernel version; it was recorded as correctly
    rounded.
  * docs/distros.md: what crmvec changes on 14 LTS distributions (glibc 2.17
    to 2.43), with craccuracy, craccuracy-zsign and cpupath to rerun it
    (make targets, not in all). libcrref.so links crmvec-roundeven.c and
    takes CRREF_OMP=, so it loads on glibc 2.17.
  * The correctly rounded library and libcrpreload.so are unchanged.

 -- anun333 <anun333@posteo.net>  Tue, 06 Oct 2026 20:50:52 -0500

crmvec (0.11.1) unstable; urgency=medium

  * CORE-MATH updated to e78b460: f16/cbrtf16.c no longer calls the C
    library's cbrtf, so crmvec-cbrtf16.h, which pointed that call at
    CORE-MATH's cbrtf, is gone. The same results: every half and bfloat16
    input of every function in four rounding modes, against MPFR, before
    and after (54,132,736 results).

 -- anun333 <anun333@posteo.net>  Tue, 06 Oct 2026 11:22:12 -0500

crmvec (0.11.0) unstable; urgency=medium

  * aarch64: libcrpreload.so, as on x86-64: CORE-MATH's 76 elementary
    functions under the C library's names (crmvec-run --libm). Checked
    against CORE-MATH on a Neoverse N1: every input of the 33 one-argument
    float functions in the four rounding modes and under FZ, and 2^20
    inputs of every function in each mode with and without FZ.
  * libcrpreload.so: errno for an underflowing exp, exp2, exp10, erfc or
    tgamma without testing the exception flag (19 ns a call, from about
    230); a whole FreeSurfer recon-all costs 13% more than with glibc,
    from 27%.
  * crmvec-stamp and crmvec-run --stamp record in a run's outputs which
    math it used; contrib/modules/ has Lmod and Tcl module files;
    docs/lab.md and docs/evidence.md.
  * CORE-MATH updated to e072473: sin.c (builds where a 128-bit integer to
    double conversion is missing) and pow.c (no spurious underflow flag in
    directed rounding). The same results on 2^24 inputs in each rounding
    mode.

 -- anun333 <anun333@posteo.net>  Mon, 05 Oct 2026 14:45:57 -0500

crmvec (0.10.0) unstable; urgency=medium

  * x86-64: a fast mode, fast/libmvec.so.1 in lib/crmvec/fast/ (crmvec-run
    --fast). Not correctly rounded: each of the 52 functions is one fixed
    sequence of IEEE operations within OpenCL's accuracy bound for it, at a
    median of 1.09 times glibc's time, and the same bits from every entry
    point on every CPU with AVX2 and FMA; elsewhere, or outside
    round-to-nearest, the correctly rounded results. The default library is
    unchanged.
  * make check-fast: every bound as the OpenCL CTS measures it, every entry
    point against the kernels, no estimate instructions, and the fallback
    under qemu without AVX2.

 -- anun333 <anun333@posteo.net>  Fri, 02 Oct 2026 20:57:35 -0500

crmvec (0.9.0) unstable; urgency=medium

  * x86-64: libcrpreload.so, installed beside libmvec.so.1 in lib/crmvec/:
    CORE-MATH's 76 correctly rounded elementary functions under the C
    library's names, for a program's scalar libm calls (LD_PRELOAD, or
    crmvec-run --libm). An FMA build and a plain x86-64 build, picked per CPU
    at load, with the same results; errno and exception flags as glibc's.
  * make check runs crpreload-check on it: 2^16 inputs a function, four
    rounding modes by four flush settings, results and flags.
  * Debian: make check passes under dpkg-buildpackage again. Since 0.6.0 its
    wrapcheck verdict read the nested make's "Leaving directory" line and
    failed the build.

 -- anun333 <anun333@posteo.net>  Fri, 02 Oct 2026 12:21:22 -0500

crmvec (0.8.0) unstable; urgency=medium

  * x86: 18 float functions (logf, log2f, log10f, log1pf, expm1f, tanhf, atanf,
    asinf, acosf, atanhf, asinhf, acoshf, cbrtf, erff, erfcf, asinpif, acospif,
    atanpif) get AVX2 vector paths in float lanes with float-pair arithmetic
    and a rounding test, CORE-MATH for the lanes it cannot decide: the same
    results on all 2^32 inputs of each, in 0.22 to 0.90 of 0.7.2's time on an
    AMD EPYC 7773X.
  * Checks: crtest verify under flush-to-zero (CRTEST_FTZ=1) and for the six pi
    functions; crmvec.c built with -Werror=undef; check-pocl.py exits 2 when
    it cannot give a verdict.
  * CORE-MATH: sinpi.c from 284b3b0 (no spurious underflow for tiny x;
    results unchanged).
  * Nix: package.nix names its check target. From 0.6.0 to 0.7.2 nix-build
    skipped make check without saying so (nixpkgs probes the target with
    make -n check, which ran the check recipe and failed before a build).

 -- anun333 <anun333@posteo.net>  Fri, 02 Oct 2026 08:19:47 -0500

crmvec (0.7.2) unstable; urgency=medium

  * x86: a vector path for double rsqrt (AVX2 and FMA; the SSE2 entry point
    goes through it), CORE-MATH's fast path transcribed; lanes it cannot
    decide go to cr_rsqrt. 2.6 times faster than CORE-MATH's scalar rsqrt
    on a Zen 3. Checked by rsqrt-vcheck, in make check, on CORE-MATH's hard
    cases at every scale, with a control that must fail.
  * CORE-MATH: powf.c and sin.c from master fe94e92, so all 165 of
    CORE-MATH's files are byte-identical to its master again. No changed
    result was found (sin: 2^26 large arguments and 1,975,928 hard cases;
    powf: 2.7 billion pairs; four rounding modes).
  * Build: mpfrcheck and pownf-search need MPFR 4.2; with an older MPFR they
    are left out instead of stopping the build.
  * crtest: CRTEST_LOG2N sets the random sample size of verify64 (and verify64e).
  * crmvec-run: --help and --version (asked for by conda-forge's review, as
    a test of the installed package); with no arguments it prints the usage
    and exits 2.

 -- anun333 <anun333@posteo.net>  Thu, 01 Oct 2026 09:55:45 -0500

crmvec (0.7.1) unstable; urgency=medium

  * CORE-MATH: powf.c from master e3f1fcc, so all 165 of CORE-MATH's files
    are byte-identical to its master again. It removes an undefined shift
    (reported 2026-09-27) that cr_powf(0x1.ffff36p-1f, 0x1.03ac88p+24f)
    reaches in 0.7.0. No changed result was found: 0 differences from
    0.7.0's powf on 2.7 billion pairs in the four rounding modes, and none
    among 40.7 million exact results in round-upward.
  * Nothing else changes.

 -- anun333 <anun333@posteo.net>  Thu, 01 Oct 2026 00:19:06 -0500

crmvec (0.7.0) unstable; urgency=medium

  * riscv64: a second copy of the 52 functions, built for VLEN 256, which the
    library uses when the CPU's VLEN is 256 (read once at load;
    CRMVEC_RV_GENERIC=1 turns it off). On a SpacemiT X60 it takes a median
    0.44 of the time, faster on all 52: 1.64 times SLEEF 3.9's time where it
    was 3.27, never slower than scalar CORE-MATH, and the same results.
    rv64-check says which build answered.
  * crtest finds glibc's libmvec where a distribution keeps it outside
    /usr/lib/x86_64-linux-gnu (openSUSE and Arch, where it was found), and
    refuses crmvec's own library if the loader path hands that back.
  * The portable core builds with clang 17 (clang 18 added
    __builtin_elementwise_sqrt).
  * The x86-64 and aarch64 libraries are unchanged from 0.6.1.

 -- anun333 <anun333@posteo.net>  Wed, 30 Sep 2026 19:53:30 -0500

crmvec (0.6.1) unstable; urgency=medium

  * Builds and runs with glibc before 2.25 (conda-forge links against 2.17).
    CORE-MATH's code calls roundeven on x86-64 without SSE4.1, and glibc has
    it only since 2.25, so 0.6.0 failed to link there under -z defs. The
    library now has its own exact roundeven and roundevenf; roundeven-check
    compares them with the C library's.
  * riscv64: rv64-bench times the 52 entry points of any libsleef.so.3
    against scalar loops; crmvec-port-rv64.c takes its block size from -DVB
    (the default is unchanged).

 -- anun333 <anun333@posteo.net>  Wed, 30 Sep 2026 16:18:47 -0500

crmvec (0.6.0) unstable; urgency=medium

  * x86: the AVX2 names (_ZGVd*) run on CPUs with AVX but not AVX2. clang
    calls them for -mavx code, and they died of SIGILL on Sandy and Ivy
    Bridge, Bulldozer and Jaguar.
  * The portable core (aarch64's default, riscv64, x86 PORT=1): pow and powf
    gave the wrong sign for x < 0 with integer y near 2^52 (pow(-1, 2^52 + 2)
    was -1). The integer test is now exact.
  * Programs built with -ffast-math (flush-to-zero on): CORE-MATH's atan2 gave
    results far off or ended the program, and logf, log2f, log10f and cbrtf
    misread subnormal inputs. Every CORE-MATH call now runs with the flush
    bits off.
  * The libraries are linked with -Bsymbolic-functions: with glibc's libmvec
    loaded first, crmvec's SVE sin could run glibc's.
  * riscv64: Sleef_fmin{d,f}x_rvvm2 carry the variant calling-convention flag,
    so lazy binding can't clobber vector registers.
  * binary16 cbrt uses CORE-MATH's cbrtf, not the C library's; unused stand-
    ins are dropped, and importcheck.sh fails the build if the library imports
    a rounding libm function.
  * x86: the AVX-512 entry points run the portable core at 512 bits (0.70
    times the old entry points' time at the median on Cascade Lake).
  * aarch64: floats 1-26% faster on Neoverse N2.
  * Checks: flush-to-zero runs, verify64e and verify2e for the AVX-512 entry
    points, an AdvSIMD-only aarch64 check; checks that tested nothing now say
    VOID and fail.
  * Build: PORT must be 0 or 1; -z defs; the distribution's CPPFLAGS and
    LDFLAGS; crmvec-run is the same on every Debian architecture.
  * CORE-MATH: cospi.c from master b1a4bad (an undefined shift fixed, the same
    results). powf.c stays at a0fce68: master's returns some exact results 1
    ulp too high in round-upward.

 -- anun333 <anun333@posteo.net>  Wed, 30 Sep 2026 14:05:08 -0500

crmvec (0.5.0) unstable; urgency=medium

  * riscv64: make riscv64 cross-builds libsleef.so.3, a stand-in for SLEEF's
    RVV library: all 86 names in LLVM's riscv64 SLEEF table and 8 of SLEEF's
    own spellings, the 52 functions from the portable core (any VLEN), the
    rest lane by lane; checked under qemu at VLEN 128 to 1024.
  * CORE-MATH updated to master a0fce68 (hypot; bfloat16 cbrt and pow, whose
    undefined shifts are fixed); the same results.

 -- anun333 <anun333@posteo.net>  Mon, 28 Sep 2026 16:32:46 -0500

crmvec (0.4.0) unstable; urgency=medium

  * Every function (all 52) in the portable core; on aarch64 none takes the
    SIMDe route by default any more: 3 to 38 ns per element on a Neoverse
    N2, against 29 to 543 through SIMDe. PORT=0 builds the previous route.

 -- anun333 <anun333@posteo.net>  Mon, 28 Sep 2026 09:00:00 -0500

crmvec (0.3.0) unstable; urgency=medium

  * aarch64: the portable core is the default (PORT defaults to 1 on
    aarch64, 0 on x86); its 35 functions are 2.3-19x faster than the SIMDe
    route on a Neoverse N2. PORT=0 builds the previous route.

 -- anun333 <anun333@posteo.net>  Mon, 28 Sep 2026 07:00:00 -0500

crmvec (0.2.1) unstable; urgency=medium

  * crmvec.h: CRMVEC_VERSION was left at 0.1.0 in 0.2.0, which failed
    make check.

 -- anun333 <anun333@posteo.net>  Mon, 28 Sep 2026 06:10:00 -0500

crmvec (0.2.0) unstable; urgency=medium

  * crmvec-simd.h: gcc reaches every function without -ffast-math.
  * make check runs on aarch64; hypotf's rounding test has a control.
  * PORT=1: 35 of the 52 functions from one portable source (off by default).
  * LICENSE.CORE-MATH: the vendored CORE-MATH files' notices.

 -- anun333 <anun333@posteo.net>  Mon, 28 Sep 2026 06:00:00 -0500

crmvec (0.1.0) unstable; urgency=medium

  * First packaged version.

 -- anun333 <anun333@posteo.net>  Sun, 27 Sep 2026 13:49:30 -0500