- ghc-tickets - Haskell.org

Re: [GHC] #5916: runST isn't free
by GHC 18 Jan '16

18 Jan '16

#5916: runST isn't free -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_run/runST Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: The new `runRW#` primop is just what the doctor ordered. See 351de169e14ad9277aaca653df4a3753c151f7bb -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5916#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2988: Improve float-in
by GHC 18 Jan '16

18 Jan '16

#2988: Improve float-in -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: lowest | Milestone: 8.2.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task * milestone: 8.0.1 => 8.2.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2988#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss"
by GHC 18 Jan '16

18 Jan '16

#11455: GHC-8.0.0.20160109 runs into "Bad interface file: ... Something is amiss" -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package | Version: 8.0.1-rc1 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I first started testing GHC-8.0.0.20160109 I could compile a lot of packages. However, now I get the following error more and more frequently: {{{ $ cabal install --with-ghc=ghc-8.0.0.20160109 --with-haddock=haddock- ghc-8.0.0.20160109 http://hackage.haskell.org/package/set-cover-0.0.8/set- cover-0.0.8.tar.gz Downloading http://hackage.haskell.org/package/set-cover-0.0.8/set-cover-0.0.8.tar.gz Resolving dependencies... Configuring enummapset-0.5.2.1... Building enummapset-0.5.2.1... Preprocessing library enummapset-0.5.2.1... [1 of 5] Compiling Data.EnumSet ( Data/EnumSet.hs, dist/build/Data/EnumSet.o ) ... [4 of 5] Compiling Data.EnumMap.Lazy ( Data/EnumMap/Lazy.hs, dist/build/Data/EnumMap/Lazy.p_o ) [5 of 5] Compiling Data.EnumMap ( Data/EnumMap.hs, dist/build/Data/EnumMap.p_o ) In-place registering enummapset-0.5.2.1... Running Haddock for enummapset-0.5.2.1... Preprocessing library enummapset-0.5.2.1... ... Registering enummapset-0.5.2.1... Installed enummapset-0.5.2.1 Configuring set-cover-0.0.8... Building set-cover-0.0.8... Preprocessing library set-cover-0.0.8... [ 1 of 15] Compiling Math.SetCover.Cuboid ( src/Math/SetCover/Cuboid.hs, dist/build/Math/SetCover/Cuboid.o ) [ 2 of 15] Compiling Math.SetCover.Queue ( src/Math/SetCover/Queue.hs, dist/build/Math/SetCover/Queue.o ) src/Math/SetCover/Queue.hs:3:1: error: Bad interface file: /home/cabal/lib/x86_64-linux- ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumMap.hi Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumMap differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumMap src/Math/SetCover/Queue.hs:4:1: error: Bad interface file: /home/cabal/lib/x86_64-linux- ghc-8.0.0.20160109/enummapset-0.5.2.1-KxKeewRMTNa4DSa3VnUuRQ/Data/EnumSet.hi Something is amiss; requested module enummapset-0.5.2.1@enummapset-0.5.2.1-64948c41f2d75b38829fcb75933a73f0:Data.EnumSet differs from name found in the interface file enumm_KxKeewRMTNa4DSa3VnUuRQ:Data.EnumSet Failed to install set-cover-0.0.8 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11455> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives
by GHC 18 Jan '16

18 Jan '16

#10958: "Annotating pure code for parallelism" docs based on old par/pseq primitives -------------------------------------+------------------------------------- Reporter: robstewartuk | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 7.10.2 Keywords: parallelim | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The example code in GHC 7.10.2 docs "7.28. Concurrent and Parallel Haskell", then in "7.15.4. Annotating pure code for parallelism" the recommendation is to use `par` and `pseq`. These primitives pre-dates the strategy combinators `rpar` and `rseq`. The example given is: {{{#!hs import Control.Parallel nfib :: Int -> Int nfib n | n <= 1 = 1 | otherwise = par n1 (seq n2 (n1 + n2 + 1)) where n1 = nfib (n-1) n2 = nfib (n-2) }}} The paper "Seq no more: Better Strategies for Parallel Haskell" ([http://www.macs.hw.ac.uk/~hwloidl/publications/strategies10.pdf] advocates `Eval` as an "evaluation order" monad, as preferable (versus `par` and `seq`) for loose control of evaluation order of parallelism. Moreover, Simon Marlow's "Parallel and Concurrent Programming in Haskell" doesn't mention the `par` and `seq` primitives at all. Should the GHC docs for "Concurrent and Parallel Haskell" encourage the use Eval combinators, either in addition to or instead of the `par` and `seq` primitives? I'd be happy to contribute an update to the docs if people agree to a shift in emphasis towards the Eval monad in the docs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10958> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11453: Kinds in type synonym/data declarations can unexpectedly unify
by GHC 18 Jan '16

18 Jan '16

#11453: Kinds in type synonym/data declarations can unexpectedly unify -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying out ideas to fix [https://github.com/ekmett/lens/issues/626 this lens issue], I noticed a couple of peculiar things about kinds in type synonym and data declarations. For example: {{{ $ /opt/ghc/head/bin/ghci -XTypeInType -XRankNTypes -XTypeOperators GHCi, version 8.1.20160113: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/xnux/.ghci λ> import Data.Kind λ> type Wat (a :: k2) (b :: k3) = forall (f :: k1 -> *). Either (f a) (f b) λ> :i Wat type Wat (a :: k1) (b :: k1) = forall (f :: k1 -> *). Either (f a) (f b) -- Defined at <interactive>:2:1 }}} This is pretty odd for two reasons. One, the kind {{{k1}}} was never specified (either existentially or as a visible kind binder), so that definition should have been rejected. But even if we do use an existential kind: {{{ λ> type Wat (a :: k2) (b :: k3) = forall k1 (f :: k1 -> *). Either (f a) (f b) λ> :i Wat type Wat (a :: k1) (b :: k1) = forall k2 (f :: k2 -> *). Either (f a) (f b) -- Defined at <interactive>:4:1 }}} We still see the second issue: GHC thinks that the type variables `a` and `b` have the same kind `k1`, when they should have separate kinds `k1` and `k2`! That behavior is very surprising to me, since it seems like GHC is choosing to unify two kind variables that should be rigid. Note that this doesn't happen if you use explicit kind binders: {{{ type Wat k2 k3 (a :: k2) (b :: k3) = forall k1 (f :: k1 -> *). Either (f a) (f b) <interactive>:6:74: error: • Expected kind ‘k1’, but ‘a’ has kind ‘k2’ • In the first argument of ‘f’, namely ‘a’ In the first argument of ‘Either’, namely ‘f a’ In the type ‘forall k1 (f :: k1 -> *). Either (f a) (f b)’ <interactive>:6:80: error: • Expected kind ‘k1’, but ‘b’ has kind ‘k3’ • In the first argument of ‘f’, namely ‘b’ In the second argument of ‘Either’, namely ‘f b’ In the type ‘forall k1 (f :: k1 -> *). Either (f a) (f b)’ }}} only when the kinds are specified but not visible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 18 Jan '16

18 Jan '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by rassilon): Replying to [comment:49 thomie]: > rassilon: you seem to know stuff. How to fix dynamic linking on Windows? Some more problems here: #4824 #5620 #7665 #8228. The "easiest" way of fixing this issue is by refactoring the GHC internals in such a way as to minimize the dependencies between the partitions of the GHC base DLL. (in short, removing all need for Haskell source level cyclic imports could help a bunch here) Either that, or come up with an automatic partitioning scheme that could handle cyclic references between the partition DLLs. The PE/COFF limitation of only being able to export 16bits worth of APIs from a dynamic library is the biggest problem of all of these issues. #5620 would only be worth addressing when we have a solution to this issue one way or another. Given that the root of the 16bit exported API problem stems from the PE/COFF specification, it would seem that any alternatives we come up would be conceptually equivalent to our current usages of non-dlopen(or equivalent) dynamic loading/linking that RTS/GHCi do today. In fact the code necessary to fix this issue would probably make that logic even more convoluted and difficult to understand/maintain. (Since the code would need to understand whatever additional sections/per-DLL API functions/etc.. that would allow the code to be relocated and linked properly.) Such a scheme would have additional downsides as well: * It would be (by necessity) be Windows specific. * It would probably completely shatter the mechanism for calling Haskell functions from C/C++ either in the same DLL or another DLL. Of the possible above approaches, I would think an automatic partitioning approach that handled cyclic references between the partitions would be the approach that had the best long term chances of successfully being maintained. Having said that of course, even automatic partitioning is still a non trivial amount of work. Since ideally, Cabal would know about DLL partitioning as well so that when anyone referenced a Haskell package with partitions, Cabal would help (or direct) GHC to link against all of the partition DLLs of that package. Ugh. Maybe it'll be easier once Microsoft lets us push a pull request to Window's dynamic linker to support more than 16bits of ordinals for Windows 20. ;) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:50> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 18 Jan '16

18 Jan '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by thomie): rassilon: you seem to know stuff. How to fix dynamic linking on Windows? Some more problems here: #4824 #5620 #7665 #8228. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11424: "Occurs check" not considered when reducing closed type families
by GHC 18 Jan '16

18 Jan '16

#11424: "Occurs check" not considered when reducing closed type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, consider the following example: {{{#!hs {-# LANGUAGE TypeFamilies #-} type family Same a b where Same a a = Int Same a b = Char example :: Same a [a] -> a example = undefined bad :: a bad = example 'c' }}} This program should type check, using the following reasoning: `a` and `[a]` can never be equal, therefore the first equation for `Same` does not apply, and so we can fall trough to the second one, thus reducing `Same` to `Char`. Therefore, `bad` should be accept. GHC rejects this program with the following error: {{{ • Couldn't match expected type ‘Same a [a]’ with actual type ‘Char’ • In the first argument of ‘example’, namely ‘'c'’ In the expression: example 'c' In an equation for ‘bad’: bad = example 'c' • Relevant bindings include bad :: a (bound at tmp/test.hs:11:1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11058: selected processor does not support ARM mode
by GHC 18 Jan '16

18 Jan '16

#11058: selected processor does not support ARM mode --------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- Building GHC-7.10.3-rc1 on Debian armel produces: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o /tmp/ghcd0b9_0/ghc_7.s: Assembler messages: /tmp/ghcd0b9_0/ghc_7.s:96:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:99:0: Error: selected processor does not support ARM mode `strd r0,r1,[r3,#64]' /tmp/ghcd0b9_0/ghc_7.s:210:0: Error: selected processor does not support ARM mode `ldrd r0,r1,[r7,#64]' /tmp/ghcd0b9_0/ghc_7.s:214:0: Error: selected processor does not support ARM mode `strd r0,r1,[r7,#64]' rts/ghc.mk:236: recipe for target 'rts/dist/build/StgStartup.o' failed make[3]: *** [rts/dist/build/StgStartup.o] Error 1 Makefile:71: recipe for target 'all' failed make[2]: *** [all] Error 2 }}} According to Austin, this is fallout from changeset:933adc0f31164cb651d11ecfcfe612ac429f714f/ghc / #10375. But it is also a regression from GHC-7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

Re: [GHC] #2374: MutableByteArray# is slower than Addr#
by GHC 18 Jan '16

18 Jan '16

#2374: MutableByteArray# is slower than Addr# -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler (NCG) | Version: 6.8.2 Resolution: | Keywords: performance | array Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, indeed there still seems to be a bit of a difference here ([[https://github.com/bgamari/T2374-benchmark|benchmark]] {{{ benchmarking ptr time 949.1 ms (945.9 ms .. 953.2 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 954.2 ms (952.3 ms .. 955.7 ms) std dev 2.470 ms (0.0 s .. 2.710 ms) variance introduced by outliers: 19% (moderately inflated) benchmarking bytearr time 989.2 ms (979.9 ms .. 997.8 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 984.2 ms (981.2 ms .. 986.3 ms) std dev 3.125 ms (0.0 s .. 3.602 ms) variance introduced by outliers: 19% (moderately inflated) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2374#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0