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).
http://darcs.haskell.org/testsuite/tests/ghc-regress/lib/Numeric/num009.hs
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.
Regards,
Malcolm
On 3 Apr 2009, at 18:58, Peter Verswyvelen wrote:
For days I'm fighting against a weird bug.
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.
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.
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.
If I manually clear these tags bits, my code works fine.
Is this something other people encountered as well? I'm trying to
make a very simple test case to reproduce the behavior...
I'm not sure if this is a visual C compiler bug, GHC bug, or
something I'm doing wrong...
Is it possible to annotate a foreign imported C function to tell the
Haskell code generator the functioin is using floating point
registers somehow?
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
