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?
- as a temporarily workaround: theproblemis not visible if the Intel C/C++ Compiler will be used instead of Microsoft C/C++.
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.