Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.

ZGETRS memory corruption(?) with denormal numbers


We recently encountered a rather strange issue when passing denormal numbers in the right-hand-side matrix to ZGETRS. Attached is a small C++ file that reproduces this error.

In this file, we set up a left- and right-hand-side matrix, factorize the lhs with ZGETRF and then call ZGETRS. Before and after the call to ZGETRS, we call the standard math fmod function with some arbitrary numbers. The call to fmod that happens before the ZGETRS call works as expected. The call afterwards however returns nan, regardless of what numbers are passed.

If the denormal numbers from the right-hand-side matrix are set to 0 instead (e.g. by uncommenting the call to _MM_SET_FLUSH_ZERO_MODE), the fmod function works as expected both times.

This issue has been reproduced on two Windows machines with the following configuration:
Operating System: Windows 7 x64
MKL: 11.2 (64bit version from Composer XE 2015)
Compiler: MSVC 9.0 (Visual Studio 2008)
Attached file compiled with: cl.exe /EHsc main.cpp /I"%MKLROOT%\include" /link -LIBPATH:"%MKLROOT%\lib\intel64" mkl_intel_lp64_dll.lib mkl_sequential_dll.lib mkl_lapack95_lp64.lib mkl_core_dll.lib



0 Kudos
2 Replies
Black Belt

If your hardware supports avx you need win7 sp1 as mkl would choose avx unless you set some mode to prevent it, such as conditional numerical reproducibility.

I thought win7 x64 would initialize to flush zero mode so you are taking chances with Microsoft libraries if you restore gradual underflow.


Apologies, SP1 is in fact installed on all machines that reproduced the issue.

Also note that we're not explicitly enabling gradual underflow, the issue with ZGETRS somehow "corrupting" fmod occurs without setting any compiler/runtime flags related to numerics. The (commented) call to _MM_SET_FLUSH_ZERO_MODE was simply included to show that explicitly setting the denormals to 0 stops the issue from occuring.