I tried both precise and fast, but that did not help. Compiling to SSE2 fixed it, since that does not use a floating point stack I guess. <div><br></div><div>I'm preparing a repro test case, but it is tricky since removing code tends to change the optimizations and then the bug does not occur. </div>
<div><br></div><div>Does anybody know what the calling convention for floating points is for cdecl on x86? The documentation says that the result is returned in st(0), but it says nothing about the floating point tags. I assume that every function expects the FP stack to be empty, potentially containing just argument values. But GHC calls the C function with some FP registers reserved on the stack...</div>
<div><br></div><div><div><div><div class="gmail_quote">On Fri, Apr 3, 2009 at 9:54 PM, Zachary Turner <span dir="ltr"><<a href="mailto:divisortheory@gmail.com">divisortheory@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
What floating point model is your DLL compiled with? There are a variety of different options here with regards to optimizations, and I don't know about the specific assembly that each option produces, but I know there are options like Strict, Fast, or Precise, and maybe when you do something like that it makes different assumptions about the caller. Although that doesn't say anything about whose "fault" it is, but at least it might be helpful to know if changing the floating point model causes the bug to go away.<div>
<div></div><div class="h5"><br>
<br><div class="gmail_quote">On Fri, Apr 3, 2009 at 2:31 PM, Peter Verswyvelen <span dir="ltr"><<a href="mailto:bugfact@gmail.com" target="_blank">bugfact@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
Well this situation can indeed not occur on PowerPCs since these CPUs just have floating point registers, not some weird dual stack sometimes / registers sometimes architecture.<div><div><br></div><div>But in my case the bug is consistent, not from time to time. </div>
<div><br></div><div>So I'll try to reduce this to a small reproducible test case, maybe including the assembly generated by the VC++ compiler. </div><div><div></div><div><div><br></div><div>On Fri, Apr 3, 2009 at 9:02 PM, Malcolm Wallace <span dir="ltr"><<a href="mailto:Malcolm.Wallace@cs.york.ac.uk" target="_blank">Malcolm.Wallace@cs.york.ac.uk</a>></span> wrote:<br>
</div><div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">Interesting. This could be the cause of a weird floating point bug that has been showing up in the ghc testsuite recently, specifically affecting MacOS/Intel (but not MacOS/ppc).<br>
<a href="http://darcs.haskell.org/testsuite/tests/ghc-regress/lib/Numeric/num009.hs" target="_blank">http://darcs.haskell.org/testsuite/tests/ghc-regress/lib/Numeric/num009.hs</a><br>
<br>
That test compares the result of the builtin floating point ops with the same ops imported via FFI. The should not be different, but on Intel they sometimes are.<br>
<br>
Regards,<br>
Malcolm<div><div></div><div><br>
<br>
On 3 Apr 2009, at 18:58, Peter Verswyvelen wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
For days I'm fighting against a weird bug.<br>
<br>
My Haskell code calls into a C function residing in a DLL (I'm on Windows, the DLL is generated using Visual Studio). This C function computes a floating point expression. However, the floating point result is incorrect.<br>
<br>
I think I found the source of the problem: the C code expects that all the Intel's x86's floating point register tag bits are set to 1, but it seems the Haskell code does not preserve that.<br>
<br>
Since the x86 has all kinds of floating point weirdness - it is both a stack based and register based system - so it is crucially important that generated code plays nice. For example, when using MMX one must always emit an EMMS instruction to clear these tag bits.<br>
<br>
If I manually clear these tags bits, my code works fine.<br>
<br>
Is this something other people encountered as well? I'm trying to make a very simple test case to reproduce the behavior...<br>
<br>
I'm not sure if this is a visual C compiler bug, GHC bug, or something I'm doing wrong...<br>
<br>
Is it possible to annotate a foreign imported C function to tell the Haskell code generator the functioin is using floating point registers somehow?<br>
</blockquote></div></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div></div></div></div></div>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br>
</div></div></blockquote></div><br></div></div></div>