math: guard __builtin_roundeven against non-glibc platforms

[kjg0724]

Problem

roundeven() and roundevenf() are C23 functions added to glibc 2.25 (2017).
On non-glibc platforms (OpenBSD, musl, Alpine Linux, etc.) they are absent.

The original condition in simde-math.h:

#if \
   (... && HEDLEY_HAS_BUILTIN(__builtin_roundeven)) || \
    HEDLEY_GCC_VERSION_CHECK(10,0,0)
  #define simde_math_roundeven(v) __builtin_roundeven(v)

On GCC 10+, __has_builtin (introduced in GCC 10) returns true for
__builtin_roundeven (also introduced in GCC 10), so the
HEDLEY_HAS_BUILTIN branch is taken. GCC lowers this builtin to a
roundeven() libm call when the hardware has no native instruction.
On platforms without roundeven in libm, this causes a link error:

undefined reference to `roundevenf'

This was observed building VVenC (which bundles SIMDE) on OpenBSD with
GCC 13: fraunhoferhhi/vvenc#680

Note: HEDLEY_GCC_VERSION_CHECK(10,0,0) in the original || branch
was dead code — on GCC 10+ the HEDLEY_HAS_BUILTIN branch always
fires first.

Fix

Guard the HEDLEY_HAS_BUILTIN path so that GCC 10+ only uses the
builtin when glibc ≥ 2.25 is present. Non-glibc platforms and old
glibc fall through to the portable inline fallback.

#if \
   ((!defined(HEDLEY_EMSCRIPTEN_VERSION) || HEDLEY_EMSCRIPTEN_VERSION_CHECK(3, 1, 43)) && \
     HEDLEY_HAS_BUILTIN(__builtin_roundeven) && \
     (!HEDLEY_GCC_VERSION_CHECK(10,0,0) || \
      (defined(__GLIBC__) && ((__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 25)))))

Why Clang is unaffected: Clang lowers __builtin_roundeven to
llvm.roundeven.* intrinsics, which LLVM always emits inline (no libm
dependency). The !HEDLEY_GCC_VERSION_CHECK(10,0,0) branch stays open
for Clang on all platforms.

Why glibc 2.25: roundeven() was added in glibc 2.25 (2017).
Checking only defined(__GLIBC__) would allow glibc 2.24 and earlier,
where the symbol is also absent.

Both simde_math_roundeven (double, line 1271) and
simde_math_roundevenf (float, line 1293) are fixed identically.

[mr-c]

Thank you!

[mr-c]

@kjg0724 if you could add one architecture + compiler combination to our CI, which would have caught this issue sooner, what would it be?

[kjg0724]

GCC 10+ on Alpine Linux (musl libc) with SIMDE_NO_NATIVE would have caught this. Alpine's musl lacks roundeven(), and SIMDE_NO_NATIVE ensures the scalar path is taken, forcing GCC to emit an actual roundeven() libm call rather than inlining it as a ROUNDSD/FRINTN instruction. This would be straightforward to add as a Docker-based CI job, complementing the existing glibc-based Ubuntu/Fedora coverage.

[mr-c]

GCC 10+ on Alpine Linux (musl libc) with SIMDE_NO_NATIVE would have caught this. Alpine's musl lacks roundeven(), and SIMDE_NO_NATIVE ensures the scalar path is taken, forcing GCC to emit an actual roundeven() libm call rather than inlining it as a ROUNDSD/FRINTN instruction. This would be straightforward to add as a Docker-based CI job, complementing the existing glibc-based Ubuntu/Fedora coverage.

Thank you! Can you add this to our CI matrix? You are welcome to use whichever CI provider you please (minor bonus if it isn't GitHub Actions as we have so many there already).

[mr-c]

And if you could squash your existing 3 commits into one, that would be appreciated. I can do it myself, but maybe you would craft the combined commit message better than I would.