Bug 922457 – dev-python/numpy-1.26.2 -Werror=lto-type-mismatch

• Status: UNCONFIRMED
• Product: Gentoo Linux

[Description Arniii 2024-01-19 06:19:08 UTC]

Created attachment 882587 [details]
buiild.log

../numpy-1.26.2/numpy/core/src/multiarray/experimental_public_dtype_api.c:389:1: error: type of ‘PyUFunc_AddLoopFromSpec’ does not match original declaration [-Werror=lto-type-mismatch]
  389 | PyUFunc_AddLoopFromSpec(PyUFuncObject *ufunc, PyObject *info, int ignore_duplicate);
      | ^
../numpy-1.26.2/numpy/core/src/umath/dispatching.c:154:1: note: type mismatch in parameter 3
  154 | PyUFunc_AddLoopFromSpec(PyObject *ufunc, PyArrayMethod_Spec *spec)
      | ^
../numpy-1.26.2/numpy/core/src/umath/dispatching.c:154:1: note: type ‘void’ should match type ‘int’
../numpy-1.26.2/numpy/core/src/umath/dispatching.c:154:1: note: ‘PyUFunc_AddLoopFromSpec’ was previously declared here
../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.h:15:1: error: type of ‘arr_interp_complex’ does not match original declaration [-Werror=lto-type-mismatch]
   15 | arr_interp_complex(PyObject *, PyObject *const *, Py_ssize_t, PyObject *, PyObject *);
      | ^
../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.c:667:1: note: type mismatch in parameter 5
  667 | arr_interp_complex(PyObject *NPY_UNUSED(self), PyObject *const *args, Py_ssize_t len_args,
      | ^
../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.c:667:1: note: ‘arr_interp_complex’ was previously declared here
../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.h:13:1: error: type of ‘arr_interp’ does not match original declaration [-Werror=lto-type-mismatch]
   13 | arr_interp(PyObject *, PyObject *const *, Py_ssize_t, PyObject *, PyObject *);
      | ^
../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.c:497:1: note: type mismatch in parameter 5
  497 | arr_interp(PyObject *NPY_UNUSED(self), PyObject *const *args, Py_ssize_t len_args,
      | ^
../numpy-1.26.2/numpy/core/src/multiarray/compiled_base.c:497:1: note: ‘arr_interp’ was previously declared here

[Comment 1 Arniii 2024-01-19 06:19:58 UTC]

Created attachment 882588 [details]
environment

[Comment 2 Sam James 2024-01-19 06:20:12 UTC]

We may be able to workaround this on a nicer level like Eli did with scipy.

[Comment 3 Arniii 2024-01-19 06:20:59 UTC]

Created attachment 882589 [details]
make.conf

[Comment 4 Arniii 2024-01-19 06:23:21 UTC]

same error at numpy-1.26.3

[Comment 5 Sam James 2024-01-19 06:24:08 UTC]

(In reply to Sam James from comment #2)
> We may be able to workaround this on a nicer level like Eli did with scipy.

i.e. https://github.com/scipy/scipy/pull/19857 rather than wholescale filter

[Comment 6 Sam James 2024-01-19 06:24:33 UTC]

ugh, this is kind of nasty -- it's clashing with an experimental API rework?

[Comment 7 Eli Schwartz 2024-02-11 21:14:24 UTC]

To clarify, the SciPy changes made sense to upstream because it affected some particularly old Fortran code that needs either serious modernization or to be replaced with brand new cython-based logic. And they'd rather the latter, I believe.

What this means is that LTO failures are both "expected" and "we will never fix this, good luck", so it makes sense to disable it altogether there. I suspect they'd rather a proper fix for numpy, if it affects new code...

[Comment 8 Sam James 2024-03-01 07:26:06 UTC]

These warnings got indirectly reported at https://github.com/numpy/numpy/issues/25642.

[Comment 9 Sam James 2024-03-05 09:20:18 UTC]

I wonder if there's a way to disable building the experimental API.

[Comment 10 Arniii 2024-03-13 12:26:18 UTC]

reproducible with numpy-1.26.4