update openblas to 0.3.27

[mattip]

Reference issue

Closes #20531

What does this implement/fix?

Update to OepnBLAS 0.3.27 to fix a problem with SVD on arm64

Additional information

[rgommers]

Thanks Matti. CI is having a really bad day, unrelated to this PR.

[neutrinoceros]

Thanks @mattip !

[tylerjereddy]

I'll tentatively add a backport label, though I did not reproduce locally with OpenBLAS swaps for whatever reason.

[rgommers]

LGTM, let's give this a go. Thanks @mattip, all

[rgommers]

Backporting seems like a good idea. Although the backport PR should run the wheel builds to make doubly sure everything is good there I think.

[neutrinoceros]

Can I ask what's the expected timeline for this to be released ? I know scipy 1.13 happened off-schedule but when is 1.14 planned for ?

[lucascolley]

when is 1.14 planned for ?

https://discuss.scientific-python.org/t/proposed-release-schedule-for-scipy-1-14-0/

[ilayn]

Strangely enough I've hit Reference-LAPACK/lapack#980 which is fixed in OpenBLAS 0.3.27 OpenMathLib/OpenBLAS#4484

We (are going to) use this in the linalg.interpolative rewrite (#20558) hence would be nice to have it indeed backported.

[rgommers]

Older OpenBLAS versions are going to be around for several more years (e.g. in Linux distros), so is it possible to find a workaround or a fallback?

[ilayn]

If we ship the wheels with new OpenBLAS 0.3.27 then the chances of hitting the bug (by old OpenBLAS version) really goes down by a lot. This is a corner case when some interim data is very small and hard to hit. I accidentally created it in my tests so it needs some effort to be hit by it. However, nice to have it fixed anyways. Anyways, long story short, it is a minute issue and can be fixed over time.

Not many folks are using interpolative anyways.