#4391: forkIO threads do not properly save/restore the floating point 
environment
---------------------------------+------------------------------------------
    Reporter:  draconx           |        Owner:              
        Type:  bug               |       Status:  new         
    Priority:  normal            |    Milestone:  7.2.1       
   Component:  Runtime System    |      Version:  6.12.3      
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  x86_64 (amd64)    |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by rwbarton):

 Perhaps a better question is whether it affects "ordinary" programs, where
 by "ordinary" programs I mean ones that don't invoke the `fe*` family of
 functions (via the FFI) or the equivalent.  My understanding is that it
 does not, but I am not an expert on the subject; please correct me if I am
 wrong.

 If your program ''does'' write the rounding mode register or read from the
 exception register, then this behavior of `forkIO` is not the only problem
 you'll have: the Prelude exports the floating point arithmetic operations
 as pure functions, even though they depend on the rounding mode and can
 raise exceptions.  This obviously breaks referential transparency and
 compiler optimizations, so you could say that even the Prelude is "broken"
 under these conditions.  Asking "how much code on hackage is broken in
 this regard" is meaningless, unless you think there a lot of code on
 hackage which goes and mucks with the floating point state on unsuspecting
 programs (seems unlikely to me).

 It would be nice to mention in the documentation, maybe in section
 "12.1.2. GHC's interpretation of undefined behaviour in Haskell 98" under
 "Unchecked float arithmetic", that GHC does not manage the floating point
 rounding or exception registers in any way; in particular, they are not
 saved or restored by Haskell thread switches, and accessing them directly
 in conjunction with using built-in floating point operations causes
 undefined behavior.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4391#comment:6>
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