Community
cancel
Showing results for 
Search instead for 
Did you mean: 
jaewonj
Novice
117 Views

Interesting behavior of dsyevr and zheevr

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?

Thanks.

Jaewon






0 Kudos
6 Replies
Gennady_F_Intel
Moderator
117 Views

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
Gennady_F_Intel
Moderator
117 Views

- as a temporarily workaround: theproblemis not visible if the Intel C/C++ Compiler will be used instead of Microsoft C/C++.
--Gennady
jaewonj
Novice
117 Views

Thanks Gennday.

As a workaround, I added a dummy call to fmod right after those two Lapack functions. I'm really curious how this happened.




Michael_C_Intel4
Employee
117 Views

Hi Jaewon,

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.

Michael.
Michael_C_Intel4
Employee
117 Views

Jaewon,

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.

Michael.
jaewonj
Novice
117 Views

Hi Michael,

I didn't know. Thank you so much for your time.

Best,
Jaewon


Reply