Repository navigation
BUG: always ignore FPE when Accelerate is the BLAS backend - #30255
Conversation
|
Just want to report I've been running my reproducer from #30162 in a loop for 40min and never hit the exception. I think I can safely conclude that the fix is confirmed. Thanks Matti ! |
|
Thanks Matti. I would have stuck a |
|
Do the Apple developer team know about this bug? (Sorry if I missed the report). |
|
I did ping @Developer-Ecosystem-Engineering in the issue but will do so again here |
|
@mattip I think we need to remove that silly warning that I added if this is flaky? I mean, just deleting is fine, it was maybe a bad idea to begin with. |
|
I think the warning is fine. Let's see if we get reports of it triggering. |
Hi Matt, We saw it =) No update at the moment but it's in the queue. |
Fixes #30162 which seems to be a regression in Accelerate. It started happening when we moved to a newer macOS image in CI (not an M4 machine) and was independently reported by @neutrinoceros on macOS 15.7.1 with an M2 machine.
Continuation of #30102. Set the default
blas_supports_fpe=falsewhen compiling with Accelerate to "ignore all FPE in calls to BLAS". #30102 added a check when importing NumPy to see if a simple matmul triggers an FPE. If so, thenblas_supports_fpeis set tofalse. But since the check is flaky it does not reliably set the value tofalseand we see FPE warnings.Downstream packagers like conda that allow switching out the blas support from Accelerate to OpenBLAS to MKL and others will have to develop a patch to deal with the flaky Accelerate library and FPEs. The available handles are:
blas_supports_fpe=falseand never see the warnings, at the cost of not knowing when overflow/underflow/divide-by-zero occursnumpy._core._multiarray_umath._blas_supports_fpe(False)when Accelerate is swapped in, to work around the flaky FPE false-positives.