I found a pretty interesting MKL behavior.
fmod (math.h) returns a garbage number if it's called right after dsyevr or zheevr.
It seems the problem only happens on 64-bit Windows.
Could you tell me what causes the problem?
yes, this is strange, but it is true. There no problems on win32. We will check what's going on with this case and will back to you asap.--Gennady
- as a temporarily workaround: theproblemis not visible if the Intel C/C++ Compiler will be used instead of Microsoft C/C++.--Gennady
As a workaround, I added a dummy call to fmod right after those two Lapack
functions. I'm really curious how this happened.
I'm debugging your testcase. Here's what I've found.
fmod relies on the specific status word contents, but for some reason MKL changes the status word. In the particular case fmodgoes to an exception route because it doesn't expect this specific status word.
To my experience, this issue happens with Microsoft cl only, but not with Intel compiler.
I'm going to narrow down the issue and fix it in the upcoming MKL update.
Thank you for the good testcase.
I have an update on this issue.
First, fmod issue on x64 is a known MS issueposted at http://support.microsoft.com/kb/972497, so use this functionwith cautionin x64, or use Intel compiler where there's no issue with fmod.
Second, changing SW is legitimate by callee, that is, by MKL, the callee doesn't have to restore SW on exit.
So we won't change MKL behaviour regarding to this issue.
I didn't know. Thank you so much for your time.