#2724: foreign functions called from optimized Haskell code receive non-empty 
fpu
stack
------------------------------+---------------------------------------------
 Reporter:  aruiz             |          Owner:  igoo   
     Type:  merge             |         Status:  new    
 Priority:  high              |      Milestone:  6.10.2 
Component:  Compiler (NCG)    |        Version:  6.8.3  
 Severity:  normal            |     Resolution:         
 Keywords:                    |     Difficulty:  Unknown
 Testcase:                    |   Architecture:  x86    
       Os:  Unknown/Multiple  |  
------------------------------+---------------------------------------------
Changes (by simonmar):

  * owner:  => igoo
  * type:  bug => merge

Comment:

 I believe this patch fixes it.  At least, with this patch, the `hoco`
 example above doesn't complain about NaN (it complains about failing
 QuickCheck tests instead, but that's what the other versions of the test
 do).

 {{{
 Tue Nov 11 12:56:19 GMT 2008  Simon Marlow <[EMAIL PROTECTED]>
   * Fix to i386_insert_ffrees (#2724, #1944)
   The i386 native code generator has to arrange that the FPU stack is
   clear on exit from any function that uses the FPU.  Unfortunately it
   was getting this wrong (and has been ever since this code was written,
   I think): it was looking for basic blocks that used the FPU and adding
   the code to clear the FPU stack on any non-local exit from the block.
   In fact it should be doing this on a whole-function basis, rather than
   individual basic blocks.
 }}}

 Many thanks to those of you who took the time to carefully isolate this
 bug and report it in a way that enabled us to diagnose the problem.  It's
 been a subtle and long-standing bug, and it's very nice to finally have it
 fixed!

 Now what I really need is a small test case that we can add to the
 testsuite.  I've tried cutting down hmatrix with no success so far, can
 anyone help?

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2724#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Reply via email to