June 2015 - ghc-tickets

[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 29 Sep '15

29 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

[GHC] #10555: RULE left-hand side too complicated to desugar
by GHC 24 Sep '15

24 Sep '15

#10555: RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: yes | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHC version 7.10.1.20150612 breaks the `fast-math` package, which compiled fine on GHC 7.10.1. To reproduce, run `cabal install fast-math`. {{{ Numeric/FastMath/Approximation.hs:60:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> +## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> +## wild_00 }) wild_00 } Numeric/FastMath/Approximation.hs:63:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_X2 { __DEFAULT -> -## wild_X2 }) wild_00 } Orig lhs: case /## y2 x of wild_00 { __DEFAULT -> (case /## y1 x of wild_00 { __DEFAULT -> -## wild_00 }) wild_00 } Numeric/FastMath/Approximation.hs:103:1: Warning: RULE left-hand side too complicated to desugar Optimised lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_X2 { __DEFAULT -> minusFloat# wild_X2 }) wild_00 } Orig lhs: case divideFloat# y2 x of wild_00 { __DEFAULT -> (case divideFloat# y1 x of wild_00 { __DEFAULT -> minusFloat# wild_00 }) wild_00 } ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150612 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired float commute left * To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 4004 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8832: Constant-folding regression wrt `clearBit (bit 0) 0 `
by GHC 24 Sep '15

24 Sep '15

#8832: Constant-folding regression wrt `clearBit (bit 0) 0 ` ------------------------------+-------------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- While implementing `zeroBits` (see [83bd2f5fc7e/base]) I noticed that constant folding of the expression `clearBit (bit 0) 0` regressed (and improved at the same time) from GHC 7.6.3 to GHC 7.8.1, specifically, the following module {{{#!haskell {-# LANGUAGE CPP #-} module M where import Data.Bits import Data.Int import Data.Word #define T(s,T) \ s :: T ; \ s = clearBit (bit 0) 0 ; \ T(i,Int) T(i8,Int8) T(i16,Int16) T(i32,Int32) T(i64,Int64) T(w,Word) T(w8,Word8) T(w16,Word16) T(w32,Word32) T(w64,Word64) T(z,Integer) }}} compiled with GHC 7.8.1RC2 results in the following Core output: {{{#!haskell -- GHC 7.8.1RC2 i = I# (andI# 1 (notI# 1)) i8 = I8# 0 i16 = I16# 0 i32 = I32# 0 i64 = I64# 0 w = W# (__word 0) w8 = W8# (__word 0) w16 = W16# (__word 0) w32 = W32# (__word 0) w64 = W64# (__word 0) z2 = $w$cbit 0 z1 = complementInteger z2 z = andInteger z2 z1 }}} Thus, `i` and `z` are not properly constant-folded in GHC 7.8.1RC2. With GHC 7.6.3, however, `i` and `z` were properly folded to `0`: {{{#!haskell -- GHC 7.6.3 i = I# 0 i8 = case $fBitsInt8_$cbit i of _ { I8# x#_aDf -> case $fBitsInt8_$cbit i of _ { I8# x#1_aDr -> I8# (word2Int# (and# (int2Word# x#_aDf) (xor# (int2Word# x#1_aDr) (__word 18446744073709551615)))) } } i16,i32,i64 -- equivalent to i8 w = W# (__word 0) w8 = case $fBitsWord8_$cbit i of _ { W8# x#_aEV -> case $fBitsWord8_$cbit i of _ { W8# x#1_aF5 -> W8# (and# x#_aEV (xor# x#1_aF5 (__word 255))) } } w16,w32,w64 -- equivalent to w8 z = __integer 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8832> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 32

[GHC] #10590: RTS failing with removeThreadFromDeQueue: not found message
by GHC 24 Sep '15

24 Sep '15

#10590: RTS failing with removeThreadFromDeQueue: not found message -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Under certain circumstances I'm facing RTS error, this happens when one thread is reading socket and another one closes it. Seems like that it happens when smth else is involved as I failed to trim this example Error that I see: {{{ % ./test nid://127.0.0.1:8080:0 1 test: internal error: removeThreadFromDeQueue: not found (GHC version 7.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ./test }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10413: Incorrect offsets for array size indexing
by GHC 24 Sep '15

24 Sep '15

#10413: Incorrect offsets for array size indexing -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There are several cases in the array code generation where a byte offset is used when a word offset is needed. For example ([https://git.haskell.org/ghc.git/blob/eb6ca851f553262efe0824b8dcbe64952de496… context]): {{{#!hs emitPrimOp dflags [res] SizeofSmallArrayOp [arg] = emit $ mkAssign (CmmLocal res) (cmmLoadIndexW dflags arg (fixedHdrSizeW dflags + oFFSET_StgSmallMutArrPtrs_ptrs dflags) (bWord dflags)) }}} This only works because `oFFSET_StgSmallMutArrPtrs_ptrs dflags` is zero. I don't have time to fix this now, but I'm reporting it so it isn't forgotten. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10495: Total inability to infer type for coerce
by GHC 24 Sep '15

24 Sep '15

#10495: Total inability to infer type for coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I say {{{ import Data.Coerce foo = coerce }}} I get {{{ Couldn't match representation of type ‘a0’ with that of ‘b0’ ‘a0’ is untouchable inside the constraints: () bound by the inferred type of foo :: a0 -> b0 at /Users/rae/temp/bug/App.hs:3:1-12 Relevant bindings include foo :: a0 -> b0 (bound at /Users/rae/temp/bug/App.hs:3:1) In the expression: coerce In an equation for ‘foo’: foo = coerce }}} How awful. Eta-expanding `foo` works fine, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10495> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6