| 14 Apr 2026 |
 emily | have we reported that we're still seeing failures upstream to OpenBLAS btw? | 13:15:05 |
 Yureka (she/her) | No | 13:15:22 |
| Yureka (she/her) | But there are no failures in the openblas test suite with their upstream fix anymore | 13:15:33 |
| emily | might incentivize them figuring out "root cause likely to be some missing or improper declaration in the inline assembly" | 13:15:44 |
| Yureka (she/her) | only failures in the scipy test suite | 13:15:37 |
| emily | (from https://github.com/OpenMathLib/OpenBLAS/pull/5691) | 13:15:48 |
| Yureka (she/her) | Would still be good to report to them igs but no time | 13:15:52 |
| emily | they originally adjusted it for https://github.com/numpy/numpy/issues/30816 | 13:16:16 |
| emily | so I guess they're probably interested in downstream failures too | 13:16:25 |
 vcunat | It's surely fishy, though. Their change causing scipy test regressions. | 13:16:44 |
| vcunat | * It's surely fishy, though. Their changes causing scipy test regressions. | 13:16:53 |
| Yureka (she/her) | not too surprising if scipy uses openblas for those calculations | 13:17:05 |
| emily | messing around with volatile is never going to be a very reliable way to make broken code compile right 🫠| 13:17:16 |
| vcunat | An alternative could be to let scipy upstream figure this out, but from what's been discussed here it does sound more likely to be an openblas issue. | 13:19:38 |
| Yureka (she/her) | Indeed but we can still report it to scipy with the hint that the failure was introduced by this openblas change | 13:20:02 |
