]> git.ipfire.org Git - thirdparty/glibc.git/commit
math: Order signed zeros in f{max,min}{f,l,f128}
authorAdhemerval Zanella <adhemerval.zanella@linaro.org>
Fri, 23 Jan 2026 13:02:20 +0000 (10:02 -0300)
committerAdhemerval Zanella <adhemerval.zanella@linaro.org>
Mon, 2 Feb 2026 17:35:19 +0000 (14:35 -0300)
commitbdb07a03fb2f7601ecba7264adb452d9355a93ef
tree5585b2acb9e7c37a8671fa0d9fc9ee8f49d1b3b8
parentd8658e02d55d563b5a064efce868b1a2cd2b44be
math: Order signed zeros in f{max,min}{f,l,f128}

The C standard (at least from C99 until C23) does not require
fmin/fmax to order zeros by their sign, so glibc's previous behavior
was entirely standards-conforming.  However, the standard does
recommend that zeros be ordered in a footnote, saying:

"If possible, fmax is sensitive to the sign of zero, for example
fmax(−0.0, +0.0) ideally returns +0."

As this is indeed possible (and not too complicated), implement it as
a quality-of-implementation improvement.  It also remove possible
deviations between architectures, where for some architectures that
has direct mapping instruction (USE_FMA*_BUILTIN) they already do
the ordering.

Checked on x86_64-linux-gnu, aarch64-linux-gnu, i686-linux-gnu,
arm-linux-gnueabihf, powerpc64le-linux-gnu,
riscv64-linux-gnu-rv64imafdc-lp64d, and loongarch64-linux-gnuf64.

Co-authored-by: James Y Knight <jyknight@google.com>
Reviewed-by: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
manual/arith.texi
math/libm-test-fmax.inc
math/libm-test-fmin.inc
math/s_fmax_template.c
math/s_fmin_template.c