[BUG]: Numpy test failure on ppc64le architecture

[susilehtola]

Required prerequisites

• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker and Discussions to verify that this hasn't already been reported. +1 or comment there if it has.
• Consider asking first in the Gitter chat room or in a Discussion.

Problem description

After applying #3682, pybind 2.9.1 successfully builds with numpy 1.22.0 on several Fedora architectures.
https://koji.fedoraproject.org/koji/taskinfo?taskID=82606547

The tests fail, however, on ppc64le:

=================================== FAILURES ===================================
________________________________ test_recarray _________________________________
simple_dtype = dtype({'names': ['bool_', 'uint_', 'float_', 'ldbl_'], 'formats': ['?', '<u4', '<f4', '<f16'], 'offsets': [0, 4, 8, 16], 'itemsize': 32})
packed_dtype = dtype([('bool_', '?'), ('uint_', '<u4'), ('float_', '<f4'), ('ldbl_', '<f16')])
    def test_recarray(simple_dtype, packed_dtype):
        elements = [(False, 0, 0.0, -0.0), (True, 1, 1.5, -2.5), (False, 2, 3.0, -5.0)]
    
        for func, dtype in [
            (m.create_rec_simple, simple_dtype),
            (m.create_rec_packed, packed_dtype),
        ]:
            arr = func(0)
            assert arr.dtype == dtype
            assert_equal(arr, [], simple_dtype)
            assert_equal(arr, [], packed_dtype)
    
            arr = func(3)
            assert arr.dtype == dtype
            assert_equal(arr, elements, simple_dtype)
            assert_equal(arr, elements, packed_dtype)
    
            # Show what recarray's look like in NumPy.
            assert type(arr[0]) == np.void
            assert type(arr[0].item()) == tuple
    
            if dtype == simple_dtype:
>               assert m.print_rec_simple(arr) == [
                    "s:0,0,0,-0",
                    "s:1,1,1.5,-2.5",
                    "s:0,2,3,-5",
                ]
E               AssertionError: assert ['s:0,0,0,6.9...6.95329e-310'] == ['s:0,0,0,-0'... 's:0,2,3,-5']
E                 At index 0 diff: 's:0,0,0,6.95329e-310' != 's:0,0,0,-0'
E                 Use -v to get the full diff
../../tests/test_numpy_dtypes.py:205: AssertionError
=============================== warnings summary ===============================

Reproducible example code

No response

[Skylion007]

@henryiii @rwgk Hurray for floating point comparisons... ;-;

[rwgk]

Why is there a -0.0 in the input?

elements = [(False, 0, 0.0, -0.0), (True, 1, 1.5, -2.5), (False, 2, 3.0, -5.0)]

That is practically asking for trouble.

[henryiii]

Can't we make these float arrays and then compare with pytest.approx(arr)?

[rwgk]

Can't we make these float arrays and then compare with pytest.approx(arr)?

Is it exercising m.print_rec_simple or just using it because it seemed convenient?

[henryiii]

That is practically asking for trouble.

Isn’t this what tests are for? :)

[charlesbeattie]

Do we know why the behaviour changed?

[henryiii]

Is this a change in NumPy on that arch? (in other words, does 1.21 produce the old behavior? Do we know?)

[susilehtola]

The package builds on Fedora 35 but fails on rawhide. They have different versions of GCC, numpy, and other thirds…

[rwgk]

(sorry for posting this in the wrong window before)

The -0 was introduced in this commit:

f7f5bc8

@jagerman Do you remember if there was a special reason for the -? Would there be anything lost if we changed it to e.g. -1?

[henryiii]

FYI, NumPy is very broken on ppc64le:

$ docker run --platform linux/ppc64le --rm -it continuumio/miniconda3:latest bash
# conda install numpy
# python

>>> import numpy as np
>>> np.array([1., 2., 3., 1.00001]).astype(np.float32)
array([0.0000000e+00, 0.0000000e+00, 0.0000000e+00, 4.5436204e+36],
      dtype=float32)

No pybind11 required. ;)

numpy/numpy#21062

[rwgk]

Whoa! OMG. Close this?

[Skylion007]

Ping @susilehtola

[henryiii]

See numpy/numpy#20964 for more info.

[QuLogic]

Those 'NumPy' bugs are QEMU bugs. Fedora builds on real ppc64le hardware, and your sample outputs array([1. , 2. , 3. , 1.00001], dtype=float32) as expected there.

Rawhide/F36 is on GCC 12 though, so it's still possibly a compiler bug.

[QuLogic]

Similar bugs in Cython and cffi on ppc64le. It possibly has to do with the switch to IEEE long double; is pybind11 doing anything special to handle that or is it likely a NumPy issue?

Note, none of NumPy's tests fail on ppc64le.

[QuLogic]

@susilehtola there were some fixes in gcc that fixed Cython, and partially cffi, so could you try rebuilding pybind11?

[susilehtola]

@susilehtola there were some fixes in gcc that fixed Cython, and partially cffi, so could you try rebuilding pybind11?

The package indeed built now without problems on all architectures. Thanks!