I've been noticing sporadic failures on the Windows cp311 (build sdist + wheel), full, no pythran test for a while now, and I do not know what is causing it.

Per comments on #19816, I think it would be worth taking some time to document and refactor scipy/linalg/_generate_pyx.py, from which I copied a lot of code when writing scipy/linalg/_generate_blas_wrapper.py in that PR. Should I create a separate PR for that or do it here?

It would also be nice to have a CI test for MKL (or Accelerate once that's ready) to ensure the wrappers are working. FWIW, building this PR with MKL passes all tests for me locally.

With these changes, I believe I have fixed the segfaults and other issues previously seen with PROPACK on 32-bit machines

That would indeed be amazing! 🤩

Just for clarity, the segfaults not only occurred on 32-bit machines, but also 64-bit ones, see conda-forge/scipy-feedstock#200. It's mainly on windows (where your wrappers already change/fix things), and MKL, which by default has a G77 ABI AFAIU.

Includes all the changes in gh-18354.

Please try to rebase the commit from #18354 and include it here (or directly include a revert of c73e088). If you want I can do it.

Just for clarity, the segfaults not only occurred on 32-bit machines, but also 64-bit ones, [...]

In particular, it's conceivable that we need to decide on the complex type based on the convention of the fortran compiler being used. Compare for example this logic in blis.

Please try to rebase the commit from #18354 and include it here (or directly include a revert of c73e088).

An empty commit is not really helpful (won't show up in git blame etc.). Please rebase it (or a fresh revert of c73e088) to the start of this PR and layer your changes on top.

Edit: if you're not comfortable with git rebase -i, I can do this for you.

The one failure in the Linux aarch64 job isn't too concerning:

FAILED scipy/sparse/linalg/_eigen/tests/test_svds.py::Test_SVDS_PROPACK::test_svd_simple[csc_matrix-True-True-4-A1] - AssertionError: 
Not equal to tolerance rtol=1e-07, atol=3e-10

Mismatched elements: 2 / 16 (12.5%)
Max absolute difference: 6.35983951e-10
Max relative difference: 3.99680289e-15
 x: array([[ 1.000000e+00,  2.814834e-15,  2.269493e-12, -6.359840e-10],
       [ 2.814834e-15,  1.000000e+00,  5.029722e-14, -1.138435e-11],
       [ 2.269493e-12,  5.029722e-14,  1.000000e+00, -2.409678e-13],
       [-6.359840e-10, -1.138435e-11, -2.409678e-13,  1.000000e+00]])
 y: array([[1., 0., 0., 0.],
       [0., 1., 0., 0.],
       [0., 0., 1., 0.],
       [0., 0., 0., 1.]]

The Windows build failure is unrelated. I've pushed a rebase, will see if we can get CI happy here.

One more, for macOS arm64:

scipy/sparse/linalg/_eigen/tests/test_svds.py:311: in test_svds_parameter_tol
    assert error < accuracy
E   assert 2.087038755703438e-15 < 2e-15

Thanks for pointing out those warnings and investigating @rgommers! On my machine, casting the return type variable to the expected Numpy type gets rid of those warnings (3ccf67c).

Thanks for pointing out those warnings and investigating @rgommers! On my machine, casting the return type variable to the expected Numpy type gets rid of those warnings (3ccf67c).

Thanks! Works for me too, and the generated code looks better. Would you mind including my commit to disable -Wno-incompatible-pointer-types in this PR? With that and the update to the PROPACK module, this looks ready to merge.

Note the use of scipy-openblas wheels requires a scipy_ prefix, which in turn requires something like defining BLAS_SYMBOL_PREFIX=scipy_ (done by the pkgconfig file in the wheel) and using the BLAS_FUNC and CBLAS_FUNC macros.

Thanks for pointing this out @mattip! In #19816, I added a script to generate C wrappers that route all BLAS/LAPACK function calls to their properly prefixed and/or suffixed names. I plan on iterating on that PR once this one is merged.