[GHC] #7600: cgrun044 failing with LLVM backend
#7600: cgrun044 failing with LLVM backend -------------------------------+-------------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- test case cgrun044 fails currently with the LLVM backend. I believe this started with the switch to the new-code-generator. LLVM fails to compile the file due to an invalid floating point constant: {{{ /Users/davidt/bin/opt: Bug31.ll:23:155: error: floating point constant invalid for type @Bug31_floatzunumber_closure = global %Bug31_floatzunumber_closure_struct<{i64 ptrtoint ([0 x i64]* @ghczmprim_GHCziTypes_Fzh_static_info to i64), float 0x7F800000, i32 0}> }}} This is an old, annoying bug needing to be fixed for about the third time. Basically, LLVM requires all floating points (float, doubles...) be printed in IEEE 754 Double format, even single precision numbers (float). However, it expects types labeled float to be representable in IEEE 754 Single precision format... So what we do is store all floating point numbers as Double and then narrow those that are Float by trying to do 'Double -> Float -> Double'. Then we can use the same machinery to produce the output for LLVM. Annoying, GHC seems to like to optimize away these narrowing operations. If it should or shouldn't do that is questionable. I'd argue it shouldn't, but oh well. The new-code-generator seems to have defeated existing techniques for stopping the optimizer firing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7600 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7600: cgrun044 failing with LLVM backend -------------------------------+-------------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Comment(by dterei): Rather than use 'realToFrac', using the underlying operations from 'GHC.Float' of 'float2Double' and 'double2Float' seem to work and narrow as expected. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7600#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7600: cgrun044 failing with LLVM backend -------------------------------+-------------------------------------------- Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Component: Compiler (LLVM) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Blockedby: Blocking: | Related: 3676 -------------------------------+-------------------------------------------- Changes (by dterei): * related: => 3676 Comment: Actually, this doesn't seem to be due to the narrowing become a null op. It is that 'realToFrac' behaves differently with optimisations turned on or off. double2Float and co, don't seem to suffer from this. Ticket #3676 is probably related. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7600#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7600: cgrun044 failing with LLVM backend ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: 3676 | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: I wonder if there is a rewrite RULE for `realToFrac` but not for `double2Float`? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7600#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7600: cgrun044 failing with LLVM backend
---------------------------------+------------------------------------------
Reporter: dterei | Owner: dterei
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (LLVM) | Version: 7.7
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Compile-time crash
Difficulty: Unknown | Testcase:
Blockedby: | Blocking:
Related: 3676 |
---------------------------------+------------------------------------------
Comment(by davidterei@…):
commit 25f8d040a6e151237c84be380179b3c6ffb9a34c
{{{
Author: David Terei
#7600: cgrun044 failing with LLVM backend ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: 3676 ---------------------------------+------------------------------------------ Changes (by dterei): * status: new => closed * resolution: => fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7600#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#7600: cgrun044 failing with LLVM backend ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: 3676 ---------------------------------+------------------------------------------ Comment(by dterei): Simon, I thought there may be. I haven't bothered to look further at what exactly causes the difference between using 'realToFrac' Vs. 'double2Float' when optimizations are on Vs. off. FP is a scary and painful world that I don't have the courage for :). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7600#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC