#1944: round function causes cblas NaNs
---------------------------+------------------------------------------------
Reporter: SevenThunders | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.8.3
Component: Compiler | Version: 6.8.1
Severity: critical | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86
Os: Windows |
---------------------------+------------------------------------------------
Comment (by SevenThunders):
Replying to [comment:7 simonmar]:
> Presumably something in the floating-point unit state is changing in a
way that upsets the code in the cblas library. I don't know of anything
that could cause this; the native code generator does in one place
generate code that saves and restores the FPU control word, but that was
added in 6.8.2 (see #1910).
>
> To proceed we really need to know what is changing in the FPU state, so
that we can trace it back to the point at which it changed. At the very
least, we need a reproducible test case. I downloaded your files and
tried it, but it looks like I have a DLL missing:
> Using dependency walker it looks like I don't have "MSJAVA.DLL".
Although why I need that, I have no idea.
Hmmm, my dependency walker is not showing the same results. I have no
dependency on MSJAVA.dll. The dependencies I show are MSVCRT.dll,
KERNEL32.dll, NTDLL.dll. This could be because of the C runtime libraries
that you are linking to on your system. So this is what I did to try to
remove any possible variation in results.
First I recompiled my test case using GHC 6.8.2 on my intel core duo
laptop running windows xp (32 bit). It still shows the errant NaNs. I
then uploaded my atlas.dll file once again just in case. (Although the
size of the two files is identical). I then uploaded my C runtime DLLs and
the system DLLs. They should be virus free, if my virus protection
software is any good. These files are now in subdirectory CRunTime. I
suspect it's not entirely kosher to freely publish copyrighted MS software
so if you can get these to work, let me know and I will delete the system
files. You will probably temporarily have to mess with your path or put
all the DLL's in the same directory with the application to force it to
pick up the C Runtime I've provided.
The location of these binaries can be found in:
http://home.earthlink.net/~mattcbro/Test2/
Apparently igloo was able to run my test case with my binaries and
obtained some odd results so I am not alone in this.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1944#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
