These symbols would be provided by libgcc rather than glibc. You can likely work around this using --rtlib=compiler-rt to use compiler-rt instead of libgcc.

gcc certainly doesn't provide such symbols on targets like s390*-linux* which don't support _Float16.
AFAIK only aarch64, csky, gcn, x86 (and in that case for ia32 only with -msse2), nvptx and riscv do support those.

Yes, the problem is that Clang supports _Float16 on s390x, but GCC doesn't, so this currently only works with Clang's runtime library. Sorry if that was unclear. (Note that _Float16 ABI was specified in the 1.7 ABI revision.)

It's probably possible to get working behavior when building with clang and linking against libgcc by modifying the macros in https://github.com/simd-everywhere/simde/blob/69f0da1ba6ea4ef6d7a4da878bdeedd6ff902277/simde/simde-f16.h to force the fallback implementation.

After all, how could it?  Before a type like that is supported, the psABI of the architecture (if any) needs to specify what size/alignment it has, in which registers/stack slots it is passed as argument and in which registers/stack slots it is returned.
From what I can see, _Float16 has been added to the s390 ABI only in June of this year, https://github.com/IBM/s390x-abi/commit/79880d87ee03cfcbf23ed2509f40a9f19b440434 and so such support can't be in GCC 15 which has been released almost 2 months before that.
I don't see that support even on GCC trunk, but guess that might change in the upcoming months.

(In reply to Nikita Popov from comment #1)
> You can likely
> work around this using --rtlib=compiler-rt to use compiler-rt instead of
> libgcc.

Adding `--rtlib=compiler-rt` to the clang invocation failed on all architectures

> /usr/bin/ld: cannot find /usr/bin/../lib/clang/21/lib/aarch64-redhat-linux-gnu/libclang_rt.builtins.a: No such file or directory

> /usr/bin/ld: cannot find /usr/bin/../lib/clang/21/lib/i686-redhat-linux-gnu/libclang_rt.builtins.a: No such file or directory

> /usr/bin/ld: cannot find /usr/bin/../lib/clang/21/lib/ppc64le-redhat-linux-gnu/libclang_rt.builtins.a: No such file or directory

> /usr/bin/ld: cannot find /usr/bin/../lib/clang/21/lib/s390x-redhat-linux-gnu/libclang_rt.builtins.a: No such file or directory

> /usr/bin/ld: cannot find /usr/bin/../lib/clang/21/lib/x86_64-redhat-linux-gnu/libclang_rt.builtins.a: No such file or directory

https://copr.fedorainfracloud.org/coprs/packit/simd-everywhere-simde-ci-packit-clang-rt-compiler/build/9550628/

This probably also needs a BuildRequires: compiler-rt, as compiler-rt is only a weak dependency of clang, so it will not be installed by default in rpm builds.

(In reply to Nikita Popov from comment #6)
> This probably also needs a BuildRequires: compiler-rt, as compiler-rt is
> only a weak dependency of clang, so it will not be installed by default in
> rpm builds.

Thank you, Nikita Popov, that fixed this issue. But it would be far preferred if clang didn't claim to support _Float16 when it isn't going to link to a runtime library that supports it for the given platform. And from what I can see, the presence of `--rtlib=compiler-rt` is not detectable from source code: https://godbolt.org/z/TPx8EabfY

> But it would be far preferred if clang didn't claim to support _Float16 when it isn't going to link to a runtime library that supports it for the given platform.

Michael, this is not considered to be a good practice because:

1. It makes it harder for developers interacting with this feature, e.g. libgcc developers could use clang to evaluate if their implementation is working as expected.
2. It's very difficult for a compiler to cover all possible combinations an user can make. That's why projects usually adopt a configure script in order to guide users on their requirements for compiler, libraries and OS.

I see that simde uses meson, but it seems the code seems to be missing a check for _Float16 compiler support + compiler-rt on s390x on Linux.

(In reply to Tulio Magno Quites Machado Filho from comment #8)
> > But it would be far preferred if clang didn't claim to support _Float16 when it isn't going to link to a runtime library that supports it for the given platform.
> 
> Michael, this is not considered to be a good practice because:
> 
> 1. It makes it harder for developers interacting with this feature, e.g.
> libgcc developers could use clang to evaluate if their implementation is
> working as expected.

I hear you, but that is an advanced and rare use case; I would imagine that a runtime flag to clang could be added, and then by default `_Float16` would not be surfaced if a compatible linker is not chosen.

> 2. It's very difficult for a compiler to cover all possible combinations an
> user can make. That's why projects usually adopt a configure script in order
> to guide users on their requirements for compiler, libraries and OS.
> 
> I see that simde uses meson, but it seems the code seems to be missing a
> check for _Float16 compiler support + compiler-rt on s390x on Linux.

SIMDe only uses meson for building and running its tests; as a header-only library, we have no control how developers use SIMDe and therefore we strive to cope with toolchain and architecture variation as much as we can without configure scripts.