July 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 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

[GHC] #10674: Expose OSThreadID and assorted functions from Haskell
by GHC 24 Sep '15

24 Sep '15

#10674: Expose OSThreadID and assorted functions from Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Currently given two {{{ThreadId}}}s, there is no way to tell without FFI if they are running on the same OS thread. There is not even a way to ask what OS thread we are currently on: something like {{{myThreadId}}} except {{{myOsThreadId}}}. Currently to remedy this, the user has to effectively copy and paste parts of the internal rts files and use something like {{{.hsc}}} with CPP to get at this information. This is not really portable on the user side and requires nasty gutting. In the RTS the function we are interested in is at least {{{osThreadId}}}: at least with this function we can inspect current {{{OSThreadId}}} and communicate it out through an {{{MVar}}} or otherwise. So this is a feature request for an abstract type {{{OSThreadId}}} with instances of at least {{{Eq, Show}}} and a function {{{myOsThreadId :: IO OSThreadId}}}. Nice to have would be {{{osThreadId :: ThreadID -> IO OSThreadId}}} but not critical. If there is room for optimisation in GHC, functions like {{{sameOsThread :: ThreadId -> ThreadId -> IO Bool}}} would also be nice but again not critical. Not sure what to set in ticket meta-data so please change as appropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10692: Replace (SourceText, FastString) with WithSourceText data type
by GHC 24 Sep '15

24 Sep '15

#10692: Replace (SourceText,FastString) with WithSourceText data type -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz 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 | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Phab:D907 introduced `SourceText` for a number of data types, by replacing `FastString` with `(SourceText,FastString)`. Since this has an `Outputable` instance, no warnings are generated when `ppr` is called on it, but unexpected output is generated. See Phab:D1096 for an example of this. Replace the `(SourceText,FastString)` tuples with a new data type {{{#!hs data WithSourceText = WithSourceText SourceText FastString }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10692> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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] #10596: Template Haskell : getQ and putQ doesn't work
by GHC 23 Sep '15

23 Sep '15

#10596: Template Haskell : getQ and putQ doesn't work -------------------------------------+------------------------------------- Reporter: kiripon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: getQ putQ | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Functions `getQ` and `putQ` in the module `Language.Haskell.TH.Syntax` do not work. Following code is an example of this problem. The variable `x` should be `(Just B)`, but `x` is `Nothing`. {{{#!hs {-# LANGUAGE TemplateHaskell #-} module X where import Language.Haskell.TH import Language.Haskell.TH.Syntax do putQ (100 :: Int) x <- getQ :: Q (Maybe Int) -- It should print "Just 100" but "Nothing" runIO $ print x return [] }}} As a result, I get following output on compile. {{{#!hs $ ghc -fforce-recomp X.hs [1 of 1] Compiling X ( X.hs, X.o ) Nothing }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10