[Pkg-opencl-devel] Bug#1059511: Bug#1059511: pocl: FTBFS on riscv64: testsuite fails: can't link double-float modules with soft-float modules

[Andreas Beckmann]

On 18/01/2024 08.41, Bo YU wrote:
> Obviously these tests failed was due to vectors missing from riscv64
> now. This is expected I think.
> 
> The result is aligned with pocl upstream support riscv64:
> 
> ```
> In this release we improved support for RISC-V CPUs. We tested PoCL on a Starfive VisionFive 2 using a Ubuntu 23.10 preinstalled image. With LLVM 17 and GCC 13.2, 98% tests pass (only 4 tests fail out of 253).

If these tests are expected to fail, they should be annotated as such 
for riscv64 (see e.g. handing of kernel/test_printf_vectors in 
tests/kernel/CMakeLists.txt). Is there an upstream bug about these tests 
failing on risc-v?

printf is a mess on most architectures (even or especially also x86) 
since the ABI for passing the variadic parameters is not well defined, 
especially when it comes to OpenCL vector types.

> So I suspect the `LLC_HOST_CPU='` was overriden by `GENERIC` then the
> ABI was different. I will look at this more deeper.

GENERIC is a Debian specific patch to build for the LLVM default target 
(i.e. without specifying -march=$whatever), s.t. the generated code 
targets the riscv64 baseline (like all code in Debian binary packages). 
(Assuming llvm targets the same baseline cpu architecture as gcc, which 
unfortunately is not true for all Debian architectures.)
(By default upstream pocl wants to build for the native CPU which is a 
no-go for distributing binaries. In order to fully utilize capabilities 
for more modern CPUs (e.g. wider SIMD registers), pocl has a distro mode 
where the bitcode libraries are provided for multiple targets and the 
best one for the local CPU is selected at runtime. But first we should 
get a baseline build for risc-v before we look into optimizing it (i.e. 
supporting separately both CPUs without and with vector unit).

Andreas

PS: I'll look into switching pocl to llvm-16 now