the current numpy installation fails to pass a sanity check due to a bug in the windows runtime

numpy == 1.19.4 Python 64位

这个错误目前是由于ucrtbase.dll的一个新的改动引起的,改动在 Windows 10 2004/20H2 版本中引入,对应子版本号为 19041.488/19042.488。

由于AMD方面FPU调用相关的问题,ucrtbase.dll的实现被改动了,导致numpy在引入时检测失败, fmod()函数调用出现问题。而这个bug仅存在于使用openBLAS新版本Numpy 1.19.4中。



Hey everyone,

Thank you for all your patience here.

After discussions with AMD over the appropriate behavior for fmod and remainder, we have an agreed upon solution that we’re hoping to push through as quickly as possible. To set expectations, pushing changes through Windows Update still takes a long time to validate, must go through proper testing and flighting processes prior to release, and servicing releases have set schedules. My current expectation is that this will be able to be released near the end of January 2021. Once I have a clear idea of when the update will be able to be available, I will update this thread again with details.

To summarize the issue, this is an issue with the 64-bit version of fmod and remainder, as of Windows version 10.0.19041.488. In this update, there was a update to the fmod and remainder functions intended to fix a case where these functions would fail to use the FPU when the FPU stack is full. This was fixed by replacing the ‘ffree’ instructions intended to create space on the FPU stack with ‘fstp’ instructions. However, instead of popping off the top two values of the stack, the implementation erroneously only popped off one value. In addition, we found that the strategy of popping off any values prior to loading our fmod arguments to the FPU should be avoided. The new implementation will no longer pop off existing values – the FPU stack prior to calling fmod/remainder will be identical to how it appears afterwards. If there is not enough room on the FPU stack to complete the fmod/remainder calculation, the function will fail (the FPU stack is caller-saved, so this is considered a precondition issue). In order to avoid this, we have also removed FPU usage from code paths that do not require the FPU to properly calculate the result.

To workaround this issue until a fix can be serviced, I recommend the other advice given in this thread:

* 32-bit applications will not encounter this issue. It is specific to our 64-bit implementation. (Thank you @Simon Björklund)

* If you are encountering this issue specifically via NumPy/OpenBLAS, please use the NumPy version 1.19.3. (Thank you @mattip)

Thank you @Roger Andrews for the suggestion – I will be following up with the Windows team about adding this to the known issues list and a compatibility hold. I update this thread with progress on that.

As mentioned above, I will continue providing updates on this issue in this thread as the schedule becomes more clear.

Thank you again for providing all your feedback!

Steve Wishnousky
Senior Software Engineer – Visual C++ Libraries​



pip install numpy==1.19.3

参考链接:visual studio developer community