control: tag 1086108 + patch Hi,
On 2024-10-28 09:56, Michael R. Crusoe wrote: > On 26/10/2024 21.21, Aurelien Jarno wrote: > > Source: scipy > > Version: 1.13.1-5 > > Severity: important > > Tags: ftbfs upstream > > X-Debbugs-Cc: [email protected], > > [email protected] > > User: [email protected] > > Usertags: riscv64 > > Control: affects -1 + src:nipy > > Control: found -1 scipy/1.14.0-1exp5 > > > > Dear maintainer, > > > > I have been debugging the cause of the FTBFS of nipy on riscv64. It > > fails with [1]: > > > > | nipy/core/reference/tests/test_matrix_groups.py . > > | E: Build killed with signal TERM after 600 minutes of inactivity > > > > I have been able to extract a minimal reproducer calling the SciPy expm > > function: > > > > | #!/usr/bin/python3 > > | > > | import numpy as np > > | from scipy.linalg import expm > > | > > | Z = np.array([[-0.83555296, 1.23536117, -0.54084919], > > | [ 0.48341885, -0.55882754, -0.53693891], > > | [-0.14802191, -0.43249490, 0.53730155]]) > > | # Z = np.random.standard_normal((3,3)) > > | > > | orth = expm(Z - Z.T) > > > > The original code uses np.random.standard_normal but I changed that into > > a static array to always use to the same code path. Debugging further, > > it happens that the pick_pade_structure() in the Cython expm support > > code is relying on undefined behaviour (UB) to convert a non-finite > > floating point value to int in a few places [2]. According to the C++ > > standard this is an undefined behaviour: > > > > | When a finite value of real floating type is converted to an integer > > | type other than _Bool, the fractional part is discarded (i.e., the > > | value is truncated toward zero). If the value of the integral part > > | cannot be represented by the integer type, the behavior is undefined. > > > > On x86, the conversion returns 0, but on RISC-V it returns either > > INT_MIN or INT_MAX depending on the sign of the floating point value. As > > the result of this conversion is then used in a loop [3], this takes an > > eternity to execute and just appears as endless. > > > > The problem has been fixed upstream as part of the rewrite of the Cython > > code into C [4][5]. For what I understand this will go into SciPy 1.15. > > > > I am not sure how you want to get that fixed in the Debian package. I > > see two options: > > - Backport the upstream commits [4][5] > > - Change the Cython code to check if number are finite before conversion > > to int, and if not return 0. > > > > Please tell me what do you prefer, and I will work on the corresponding > > patch. > > Dear Aurelien, > > Thank you very much for your research. I think the second option is safer and > simpler. > Thanks for your fast answer. Please find the patch attached, it should work with both the scipy version in unstable and the one in experimental. I tested it against the unstable version on both amd64 and riscv64. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
signature.asc
Description: PGP signature
