Follow on to Bug in zgetrs() under Windows 10 2004

[vss_albert]

Starting an new thread since the issue in the original thread (https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/Bug-in-zgetrs-under-Windows-10-2004/td-p/1203467) was considered closed by Intel.

It appears building with the VC runtime library set to "Multi-threaded DLL" makes a difference.

With the VC runtime library set to "Multi-threaded (/MT)" and Release build, running under Windows 10 version 2004 build 19041.450 I get the correct answer:

MKL 2020.0.2Intel(R) 64 architecture
Processor: Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors
MKL_VERBOSE Intel(R) MKL 2020.0 Update 2 Product build 20200624 for Intel(R) 64 architecture Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors, Win 3.40GHz cdecl tbb_thread
MKL_VERBOSE ZGETRS(N,3,1,00000272BE1F6380,3,00000272BE1F6480,00000272BE1FDEC0,3,0) 66.96us CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:4,BLAS:1,FFT:1,VML:1,PARDISO:1
Info: 0
14.8677 -6.71688
2.89337 -7.12151
2.52554 -5.46729

With the VC runtime library set to "Multi-threaded DLL (/MD)" and Release build, running under Windows 10 version 2004 build 19041.450 I get the NaNs:

MKL 2020.0.2Intel(R) 64 architecture
Processor: Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors
MKL_VERBOSE Intel(R) MKL 2020.0 Update 2 Product build 20200624 for Intel(R) 64 architecture Intel(R) Advanced Vector Extensions 2 (Intel(R) AVX2) enabled processors, Win 3.40GHz cdecl tbb_thread
MKL_VERBOSE ZGETRS(N,3,1,0000029B87F81080,3,0000029B87F81180,0000029B87F94780,3,0) 79.11us CNR:OFF Dyn:1 FastMM:1 TID:0 NThr:4,BLAS:1,FFT:1,VML:1,PARDISO:1
Info: 0
-nan(ind) -nan(ind)
-nan(ind) -nan(ind)
-nan(ind) -5.46729

[Gennady_F_Intel]

Could you show the list of mkl libs you lined with? I see the verbose reported the tbb threading libs were used.

[vss_albert]

This is what I have for the Additional Dependencies under the Linker>Input settings:

mkl_intel_lp64_dll.lib;mkl_tbb_thread_dll.lib;mkl_core_dll.lib;tbb.lib;%(AdditionalDependencies)

Attached is a pdf version of the vcproj file.

What I have been able to determine so far is that the call to fmod() with x of 0.0 leaves the top of the floating point stack with a 1#IND at the top of the stack, here's what the FP registers look like after the fmod() call (and immediately before the zgetrs() call):

ST0 = 1#IND ST1 = +0.0000000000000000e+0000 ST2 = +0.0000000000000000e+0000 ST3 = +0.0000000000000000e+0000 ST4 = +0.0000000000000000e+0000 ST5 = +0.0000000000000000e+0000 ST6 = +0.0000000000000000e+0000 ST7 = +1.0000000000000000e+0000 CTRL = 027F STAT = 1000 TAGS = 0004 EIP = 1EB7A692 EDO = 1610F860

[Gennady_F_Intel]

Ok, thanks for the update. Having these details help to see the nan on win10, version 2004.

We escalated the issue and will keep you updated with the results.

[Gennady_F_Intel]

as is is the Microsoft but not MKL, they are working on a fix. MKL will not provide a workaround. We only added the Know Limitation into Release Notes:

https://software.intel.com/content/www/us/en/develop/articles/oneapi-math-kernel-library-release-notes.html

C/Fortan Known Issues and Limitations

• On Windows* 10 version 2004, the fmod function causes the floating point stack to be left in an incorrect state when called with the x parameter equal to zero. When certain oneMKL functions such as zgetrs are called at some point after the problematic fmod function call, the results returned may be incorrect (in particular, they may be NaNs). If possible, avoid using this version of Windows* 10 or later until a fix is provided by Microsoft*. Alternatively, after calling fmod, the floating point stack may be cleared by calling the emms instruction.

[Gennady_F_Intel]

The issue is closing and we will no longer respond to this thread. If you require additional assistance from Intel, please start a new thread. Any further interaction in this thread will be considered community only.