September 2015 - ghc-tickets

[GHC] #10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack
by GHC 24 Sep '15

24 Sep '15

#10894: In users_guide/profiling.xml : -prof flag not to be used with cabal/stack -------------------------------------+------------------------------------- Reporter: | Owner: robstewartuk | Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 7.10.2 Documentation | Keywords: user | Operating System: Unknown/Multiple guide, profiling | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The documentation for compiling with cost centre profiling support is here: https://github.com/ghc/ghc/blob/master/docs/users_guide/profiling.xml#L79 It says: {{{ Compile and run this program as follows: $ ghc -prof -fprof-auto -rtsopts Main.hs $ ./Main +RTS -p 121393 $ }}} This is not the case when cabal or stack are used, as `-prof` should be omitted, i.e. {{{ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-fprof-auto -rtsopts" }}} If the user does not know this and includes `-prof` in the --ghc-options string, they are likely to see compiler error messages relating to `p_dyn`, e.g. {{{ Failed to load interface for ‘GHC.Integer.Type’ Perhaps you haven't installed the "p_dyn" libraries for package ‘integer- gmp-1.0.0.0’? Use -v to see a list of the files searched for. }}} Given that other parts of the `profiling.xml` file does refer to cabal, do people agree that it might be helpful to make it explicit in Section "5.1. Cost centres and cost-centre stacks", that using ghc directly `-prof` should be used (no change to the XML file): {{{ $ ghc -prof -fprof-auto -rtsopts Main.hs }}} Though if cabal/stack is being used, the `-prof` should be omitted (an addition to the XML file): {{{ $ cabal install --enable-executable-profiling --enable-library-profiling --ghc-options="-fprof-auto -rtsopts" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10894> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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

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

23 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] #10660: .dyn_o isn't generated for .hsig files with -dynamic-too
by GHC 23 Sep '15

23 Sep '15

#10660: .dyn_o isn't generated for .hsig files with -dynamic-too -------------------------------------+------------------------------------- Reporter: spinda | 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 | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This causes the linker to error out later on, as it expects a .dyn_o file to exist for each .hsig file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10660> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10689: compiling singletons-1.1.2.1 as -O1 -fspec-constr fails as 'Template variable unbound in rewrite rule'
by GHC 23 Sep '15

23 Sep '15

#10689: compiling singletons-1.1.2.1 as -O1 -fspec-constr fails as 'Template variable unbound in rewrite rule' -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- First observed on singletons-1.1.2.1 package ghc-7.10.2. I've tried to distill it down to a single file. The file manages to crash both GHC and GHCi. GHCi: {{{ $ inplace/bin/ghc-stage2 -hide-all-packages -package=base --interactive List.hs GHCi, version 7.11.20150723: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling List ( List.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150723 for x86_64-unknown-linux): floatExpr tick break<2>() Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} GHC: {{{ $ inplace/bin/ghc-stage2 -hide-all-packages -package=base --make List.hs -dsuppress-all -dsuppress-uniques [1 of 1] Compiling List ( List.hs, List.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150723 for x86_64-unknown-linux): Template variable unbound in rewrite rule m [a_afdP, x, m, ipv, ipv, sc, sc, sc, sg] [a_afdP, x, m, ipv, ipv, sc, sc, sc, sg] [TYPE a_afdP, TYPE x, TYPE Let1627448493XsSym4 x m ipv ipv, sc, (SCons @~ ... sc sc) `cast` ...] [TYPE a_afdP, TYPE x, TYPE Let1627448493XsSym4 x ipv ipv ipv, sc, (SCons @~ ... ipv ipv) `cast` ...] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The "minimal" single-file sample is attached. If you need original selfcontained reproducer (79 modules, template haskell code) this is the version i've started with: http://code.haskell.org/~slyfox/unbound-template-var.tar.gz Adjusting path to GHC in '''./trigger-a-bug.bash''' should be enough. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10689> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

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

23 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] #10715: Possible regression in Coercible a (X a) between 7.8 and 7.10
by GHC 23 Sep '15

23 Sep '15

#10715: Possible regression in Coercible a (X a) between 7.8 and 7.10 -------------------------------------+------------------------------------- Reporter: inaki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- In upgrading to7.10, code of the form {{{#!hs {-# LANGUAGE FlexibleContexts #-} import Data.Coerce (coerce, Coercible) data X a doCoerce :: Coercible a (X a) => a -> X a doCoerce = coerce }}} fails to compile in 7.10.1 and 7.10.2 with the error {{{ testCoerce.hs:6:13: Could not deduce (a ~ X a) from the context (Coercible a (X a)) bound by the type signature for doCoerce :: Coercible a (X a) => a -> X a at testCoerce.hs:6:13-41 ‘a’ is a rigid type variable bound by the type signature for doCoerce :: Coercible a (X a) => a -> X a at testCoerce.hs:6:13 Relevant role signatures: type role X phantom In the ambiguity check for the type signature for ‘doCoerce’: doCoerce :: forall a. Coercible a (X a) => a -> X a To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘doCoerce’: doCoerce :: Coercible a (X a) => a -> X a }}} while it works in 7.8.4. Surprisingly (to me at least), the code works in 7.10.1 and 7.10.2 if I change it to {{{#!hs {-# LANGUAGE FlexibleContexts #-} import Data.Coerce (coerce, Coercible) data X a doCoerce :: Coercible a (X b) => a -> X a doCoerce = coerce }}} while it fails to compile in 7.8.4 with the error {{{ testCoerce.hs:6:13: Could not coerce from ‘a’ to ‘X b0’ because ‘a’ and ‘X b0’ are different types. arising from the ambiguity check for ‘doCoerce’ from the context (Coercible a (X b)) bound by the type signature for doCoerce :: Coercible a (X b) => a -> X a at testCoerce.hs:6:13-41 The type variable ‘b0’ is ambiguous In the ambiguity check for: forall a b. Coercible a (X b) => a -> X a To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature for ‘doCoerce’: doCoerce :: Coercible a (X b) => a -> X a }}} The coercion pattern may look a bit funny, but it is rather useful when one has newtypes of the form {{{#!hs newtype Y = Y (ForeignPtr Y) }}} which appear naturally when writing bindings to C libraries, and one wants to get access to the underlying ForeignPtr from Y (here X -> ForeignPtr). The relevant Coercible instance here is Coercible Y (ForeignPtr Y), as above. I would have expected the version with context "Coercible a (X a)" to be accepted, as 7.8.4 does, since it seems to be a specialization of the more general coerce, but maybe I am missing something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10715> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #10879: base is not included in the haddock index
by GHC 23 Sep '15

23 Sep '15

#10879: base is not included in the haddock index -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It appears that starting from ghc 7.10 base is no longer present in the haddock html index distributed with ghc. {{{ % grep -c base ~/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries/index.html 1 % grep -c base ~/.stack/programs/x86_64-linux/ghc-7.10.2/share/doc/ghc/html/libraries/index.html 0 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10713: Type family not reducing over data family
by GHC 23 Sep '15

23 Sep '15

#10713: Type family not reducing over data family -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Given this code, {{{ type family TEq t s where TEq t t = 'True TEq t s = 'False data family T a }}} I expected this GHCi interaction to reduce: `:kind! TEq (T Int) (T Bool)` But it does not. It does reduce (to `'True`) if you instead ask, `:kind! TEq (T Int) (T Int)` Tested on GHC 7.10.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5