August 2015 - ghc-tickets

[GHC] #9238: Negative zero broken
by GHC 03 Oct '15

03 Oct '15

#9238: Negative zero broken --------------------------+------------------------------------------------ Reporter: | Owner: augustss | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: | Operating System: Windows Compiler | Type of failure: Incorrect result at runtime Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Try the following program {{{ compareDouble :: Double -> Double -> Ordering compareDouble x y = case (isNaN x, isNaN y) of (True, True) -> EQ (True, False) -> LT (False, True) -> GT (False, False) -> -- Make -0 less than 0 case (x == 0, y == 0, isNegativeZero x, isNegativeZero y) of (True, True, True, False) -> LT (True, True, False, True) -> GT _ -> x `compare` y main = do let l = [-0, 0] print [ (x, y, compareDouble x y) | x <- l, y <- l ] }}} Compile and run with -O0 {{{ $ ghc -O0 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,LT),(0.0,-0.0,GT),(0.0,0.0,EQ)] }}} This is the correct output. Compile and run with -O1 {{{ $ ghc -O1 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,LT),(-0.0,0.0,LT),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong. Put a NOINLINE pragma on compareDouble: {{{ $ ghc -O1 D.hs [1 of 1] Compiling Main ( D.hs, D.o ) Linking D.exe ... $ ./D [(-0.0,-0.0,EQ),(-0.0,0.0,EQ),(0.0,-0.0,EQ),(0.0,0.0,EQ)] }}} This is wrong in a different way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9238> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #10745: Error in fusion when compiling Data.Yaml
by GHC 02 Oct '15

02 Oct '15

#10745: Error in fusion when compiling Data.Yaml -----------------------------------------+--------------------------------- Reporter: nclarke | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- {{{ [2 of 7] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, dist/dist- sandbox-b22ce51e/build/Data/Yaml/Internal.o ) Data/Yaml/Internal.hs:28:1: Warning: The import of ‘Control.Applicative’ is redundant except perhaps to import instances from ‘Control.Applicative’ To import instances alone, use: import Control.Applicative() ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-unknown-linux): Tick in rule unstream @ a34_ayco @ Void @ m_aycm @ b_aycn (ConduitWithStream @ a34_ayco @ Void @ m_aycm @ b_aycn (let { $dApplicative_aycu :: Applicative (ConduitM a34_ayco Void m_aycm) [LclId, Str=DmdType] $dApplicative_aycu = $fApplicativeConduitM @ a34_ayco @ Void @ m_aycm ($fFunctorConduitM @ a34_ayco @ Void @ m_aycm) } in letrec { loop_aycv :: b_aycn -> ConduitM a34_ayco Void m_aycm b_aycn [LclId, Arity=1, Str=DmdType] loop_aycv = \ (accum_aycw :: b_aycn) -> $fMonadConduitM_$c>>= @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ (Maybe a34_ayco) @ b_aycn ((await @ a34_ayco @ m_aycm $dMonad1_aycq) @ Void) (maybe @ (ConduitM a34_ayco Void m_aycm b_aycn) @ a34_ayco ($fMonadConduitM_$creturn @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ b_aycn accum_aycw) (\ (a35_aycx :: a34_ayco) -> $fMonadConduitM_$c>>= @ a34_ayco @ Void @ m_aycm $dApplicative_aycu @ b_aycn @ b_aycn ($ @ (m_aycm b_aycn) @ (ConduitM a34_ayco Void m_aycm b_aycn) ($fMonadBasebaseConduitM_$clift @ a34_ayco @ Void @ m_aycm @ b_aycn $dMonad1_aycq) (f_aycs accum_aycw a35_aycx)) (\ (accum'_aycy :: b_aycn) -> case accum'_aycy of wild_aycz { __DEFAULT -> loop_aycv wild_aycz }))); } in loop_aycv b1_ayct) (foldMS @ b_aycn @ a34_ayco @ m_aycm $dMonad1_aycq f_aycs b1_ayct @ Void)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages
by GHC 02 Oct '15

02 Oct '15

#10777: Overlong linker arguments on Windows leads to broken builds with confusing error messages -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I've seen three different issues on Github about this: two in the stack repo for stack users, and one in the yesod repo for a cabal sandbox user: https://github.com/yesodweb/yesod/issues/1020 https://github.com/commercialhaskell/stack/issues/466 https://github.com/commercialhaskell/stack/issues/795 The problem comes down to this: Windows has a limit of 32k on the size of a command string, which can be tripped by GHC's link phase when using a large number of libraries. The ideal situation would be for GHC to have a different way of passing large argument lists to the linker; I don't know how feasible this is, but I wanted to open up a ticket before I started investigating myself in case others have seen this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10475: detabify User's Guide
by GHC 02 Oct '15

02 Oct '15

#10475: detabify User's Guide -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: task | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The User's Guide .xml files use a fairly random-looking mix of tabs and spaces for indentation. Let's get rid of the tabs and then enforce their absence with git hooks. Why do this? See #10425; apparently tabs within programlisting elements are rendered as some number of spaces other than 8 in the PDF version (only!) I briefly tried to find other instances of the same issue, but there are thousands of tab characters in the User's Guide and I'm too lazy to try to find only the ones within programlisting elements. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10215: Optimizer has bugs regarding handling of -0.0
by GHC 02 Oct '15

02 Oct '15

#10215: Optimizer has bugs regarding handling of -0.0 -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #9238 Differential Revisions: | -------------------------------------+------------------------------------- This is most likely related to https://ghc.haskell.org/trac/ghc/ticket/9238 Perhaps it can be merged into that if it is indeed the case, though it'd be good for an expert to take a look and make sure first that the culprit is indeed the same. In any case, the program in this ticket can at least serve as a test-case. I observed this on 7.8.3; though I suspect the same holds in the just released 7.10.1 as well. For the following program: {{{#!hs testF :: Float -> Bool testF x = x == 0 && not (isNegativeZero x) testD :: Double -> Bool testD x = x == 0 && not (isNegativeZero x) main :: IO () main = do print $ testF (-0.0) print $ testD (-0.0) }}} If I compile with no optimizations, then I get the correct answers: {{{ $ /bin/rm -f a.hi a.o a; ghc -O0 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... False False }}} But if I turn optimizations on, then I get: {{{ $ /bin/rm -f a.hi a.o a; ghc -O2 a; ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... True True }}} which is just plain wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10392: typo in Debug.Trace.traceShowM example
by GHC 02 Oct '15

02 Oct '15

#10392: typo in Debug.Trace.traceShowM example -------------------------------------+------------------------------------- Reporter: sebastian | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- s/traceMShow/traceShowM The documentation for Debug.Trace.traceShowM has an example, where the function is called traceMShow instead of the correct traceShowM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10568: Loading GLUT into GHCI fails on the Mac, probably a regression
by GHC 29 Sep '15

29 Sep '15

#10568: Loading GLUT into GHCI fails on the Mac, probably a regression -----------------------------------------+------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+------------------------------- ghci -V The Glorious Glasgow Haskell Compilation System, version 7.10.1.20150612 ghci -package GLUT GHCi, version 7.10.1.20150612: http://www.haskell.org/ghc/ :? for help <command line>: can't load .so/.DLL for: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib (dlopen(/Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib, 5): Symbol not found: _glutBitmap8By13 Referenced from: /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib Expected in: flat namespace in /Library/Haskell/ghc-7.10.1.20150612-x86_64/lib/GLUT-2.7.0.1/libHSGLUT-2.7.0.1 -4wlNyqnZsQF9mL67dfVCyA-ghc7.10.1.20150612.dylib) This may be related to the fix for #10322. The GLUT people are aware of this. They believe it is platform scpecific, a regression and probably a ghc issue. See https://github.com/haskell-opengl/GLUT/issues/19 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10568> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 49

[GHC] #10455: No detail for profiling costs atributed to SYSTEM / PINNED / ARR_WORDS
by GHC 29 Sep '15

29 Sep '15

#10455: No detail for profiling costs atributed to SYSTEM / PINNED / ARR_WORDS -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Profiling | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using ghc's heap profiling, some allocations are treated specially in such a way that we get no useful information for them. * For +RTS -hc "cost centre stack", the allocations are classed as PINNED, which means we cannot see which cost centre allocated them. * For +RTS -hm "module", the allocations are classed as SYSTEM, which means we cannot see which module allocated them. * For +RTS -hy "type description" and +RTS -hd "closure description", the allocations are classed as ARR_WORDS, which means we cannot see what type they are (ByteArray#?). So none of these modes help us see what these allocations are or where they come from. Do these allocations have to be treated in this special way such that we loose all useful information? Presumably they are pinned ByteArray#s, but surely we can still track which cost centre to assign them to, and hence the module, and shouldn't the type/closure description be "ByteArray#" or "pinned ByteArray#" or something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10455> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9342: Branchless arithmetic operations
by GHC 28 Sep '15

28 Sep '15

#9342: Branchless arithmetic operations -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Differential Revisions: Keywords: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- While working on #9281 I noticed sub-optimal code generation for common arithmetic operations on `Int`. Below are some examples of code generation, where the branchless versions may be desirable on modern CPUs: = `abs` {{{#!hs -- base version absI# :: Int# -> Int# absI# i# = i'# where !(I# i'#) = abs (I# i#) -- optimized version optAbsI# :: Int# -> Int# optAbsI# i# = (i# `xorI#` nsign) -# nsign where -- nsign = i# <# 0# nsign = uncheckedIShiftRA# i# (WORD_SIZE_IN_BITS# -# 1#) }}} results in {{{#!asm absI#_info: _c1To: testq %r14,%r14 jge _c1Tx _c1Ty: movq %r14,%rbx negq %rbx jmp *(%rbp) _c1Tx: movq %r14,%rbx jmp *(%rbp) optAbsI#_info: _c1SX: movq %r14,%rax sarq $63,%rax movq %r14,%rbx xorq %rax,%rbx subq %rax,%rbx jmp *(%rbp) }}} = `signum` {{{#!hs sgnI# :: Int# -> Int# sgnI# i# = i'# where !(I# i'#) = signum (I# i#) optSgnI# :: Int# -> Int# optSgnI# x# = (x# ># 0#) -# (x# <# 0#) }}} {{{#!asm sgnI#_info: _c27W: testq %r14,%r14 jl _c283 _c284: testq %r14,%r14 jne _c28a _c28b: xorl %ebx,%ebx jmp *(%rbp) _c283: movq $-1,%rbx jmp *(%rbp) _c28a: movl $1,%ebx jmp *(%rbp) optSgnI#_info: _c26P: testq %r14,%r14 setl %al movzbl %al,%eax testq %r14,%r14 setg %bl movzbl %bl,%ebx subq %rax,%rbx jmp *(%rbp) }}} = `compare` {{{#!hs cmpI# :: Int# -> Int# -> Int# cmpI# x# y# = dataToTag# (compare (I# x#) (I# y#)) -- returns 0, 1 or 2, can be fed to tagToEnum# :: Ordering optCmpI# :: Int# -> Int# -> Int# optCmpI# x# y# = 1# +# (x# ># y#) -# (x# <# y#) }}} {{{#!asm cmpI#_info: _c25s: cmpq %rsi,%r14 jl _c25z _c25A: cmpq %rsi,%r14 je _c25M _c25N: movl $2,%ebx jmp *(%rbp) _c25z: xorl %ebx,%ebx jmp *(%rbp) _c25M: movl $1,%ebx jmp *(%rbp) optCmpI#_info: _c24N: cmpq %rsi,%r14 setl %al movzbl %al,%eax movl $1,%ebx subq %rax,%rbx cmpq %rsi,%r14 setg %al movq %rbx,%rcx movzbl %al,%ebx addq %rcx,%rbx jmp *(%rbp) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9342> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9079: Foreign.C.Types in haskell2010
by GHC 27 Sep '15

27 Sep '15

#9079: Foreign.C.Types in haskell2010 -----------------------------------------+--------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell2010 | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -----------------------------------------+--------------------------------- According to Haskell 2010, a marshallable foreign type has to be a `newtype` of a basic type with exposed constructor. Why constructors are not exposed in the module `Foreign.C.Types` from `haskell2010`? When I replace `base` with `haskell2010` in {{{ module Test where import Foreign.C foreign import ccall unsafe "sys/mount.h umount" umount :: CString -> IO CInt }}} I get {{{ Unacceptable result type in foreign declaration: IO CInt When checking declaration: foreign import ccall unsafe "static sys/mount.h umount" umount :: CString -> IO CInt }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9079> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7