test_clmath.py::test_fmod fails on i386 using pocl 3.1 built with llvm 15

[anbe42]

Debian CI noticed a pyopencl autopkgtest regression on i386 when using pocl 3.1 (built with llvm 15).

The only change that I'm aware of is that I recently switched the pocl build from llvm 14 to llvm 15, all other versions should be unchanged.

https://ci.debian.net/data/autopkgtest/testing/i386/p/pyopencl/30825012/log.gz

=================================== FAILURES ===================================
_ test_fmod[<context factory for <pyopencl.Device 'pthread-i686-AMD EPYC 7571' on 'Portable Computing Language'>>] _

ctx_factory = <pyopencl.tools._ContextFactory object at 0xf54e7dd8>

    def test_fmod(ctx_factory):
        context = ctx_factory()
        queue = cl.CommandQueue(context)

        for s in sizes:
            a = cl_array.arange(queue, s, dtype=np.float32)/10
            a2 = cl_array.arange(queue, s, dtype=np.float32)/45.2 + 0.1
            b = clmath.fmod(a, a2)

            a = a.get()
            a2 = a2.get()
            b = b.get()

            for i in range(s):
>               assert math.fmod(a[i], a2[i]) == b[i]
E               assert 0.13451331853866577 == 0.13451329
E                +  where 0.13451331853866577 = <built-in function fmod>(0.6, 0.23274335)
E                +    where <built-in function fmod> = math.fmod

test_clmath.py:172: AssertionError
=============================== warnings summary ===============================
...
=========================== short test summary info ============================
FAILED test_clmath.py::test_fmod[<context factory for <pyopencl.Device 'pthread-i686-AMD EPYC 7571' on 'Portable Computing Language'>>]
= 1 failed, 305 passed, 7 skipped, 2 xfailed, 33 warnings in 701.40s (0:11:41) =

I can reproduce that locally, too, in an i386 chroot in case you need further information for debugging this.

This is not neccessarily a bug in pyopencl, but it could also be further down in the dependency chain (pocl, llvm, ...)

[inducer]

I think the bug is in that test in this case. There's no reason why fmod would be exact. See #676.

[inducer]

Also, thanks for the report.