November 2015 - ghc-tickets

[GHC] #9579: Runtime suggests using +RTS when that's not possible
by GHC 15 Nov '15

15 Nov '15

#9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I just ran into a stack overflow in an application, and GHC told me: Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it. I tried to specify +RTS and got an error saying "Most RTS options are disabled. Link with -rtsopts to enable them." The runtime should not suggest using +RTS when that is not possible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

Re: [GHC] #9555: internal error: ARR_WORDS object entered!
by GHC 15 Nov '15

15 Nov '15

#9555: internal error: ARR_WORDS object entered! -------------------------------------+------------------------------------- Reporter: walck | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Old description: > In ghci, > > :m Data.Complex.Cyclotomic > goldenRatio > > produces the error. > > <interactive>: internal error: ARR_WORDS object entered! > (GHC version 7.8.3 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Aborted (core dumped) New description: In ghci, {{{ :m Data.Complex.Cyclotomic goldenRatio }}} produces the error. {{{ <interactive>: internal error: ARR_WORDS object entered! (GHC version 7.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} -- Comment: I am unable to reproduce this with 7.10.2. Closing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9555#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11052: Standalone derived Typeable instance for promoted lists is not found
by GHC 15 Nov '15

15 Nov '15

#11052: Standalone derived Typeable instance for promoted lists is not found -------------------------------------+------------------------------------- Reporter: liamoc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- On GHC 7.10.2, if I try and compile the following short program: {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, DeriveDataTypeable, StandaloneDeriving #-} module Test where import Data.Typeable deriving instance Typeable '[] deriving instance Typeable '(:) nilTyCon = typeRepTyCon (typeRep (Proxy :: Proxy '[])) consTyCon = typeRepTyCon (typeRep (Proxy :: Proxy '(:) )) }}} Then GHC reports the following errors: {{{ Test.hs:9:27: No instance for (Typeable '[]) arising from a use of ‘typeRep’ In the first argument of ‘typeRepTyCon’, namely ‘(typeRep (Proxy :: Proxy '[]))’ In the expression: typeRepTyCon (typeRep (Proxy :: Proxy '[])) In an equation for ‘nilTyCon’: nilTyCon = typeRepTyCon (typeRep (Proxy :: Proxy '[])) Test.hs:10:27: No instance for (Typeable (':)) (maybe you haven't applied enough arguments to a function?) arising from a use of ‘typeRep’ In the first argument of ‘typeRepTyCon’, namely ‘(typeRep (Proxy :: Proxy (:)))’ In the expression: typeRepTyCon (typeRep (Proxy :: Proxy (:))) In an equation for ‘consTyCon’: consTyCon = typeRepTyCon (typeRep (Proxy :: Proxy (:))) }}} It seems a bug to me that the very instances I asked to be derived (and apparently were without complaint from GHC) are now not found by the typechecker in the very next line. I think that if the instance cannot be derived, GHC should say so, or if it can, then GHC should find it. I can't really see what's going on with the dump flags, because the typechecker fails before the desugarer runs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11052> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11075: Confusing parallel spark behaviour with safe FFI calls
by GHC 15 Nov '15

15 Nov '15

#11075: Confusing parallel spark behaviour with safe FFI calls -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a tricky problem, and I don't see any easy solution, but here it is for the sake of documenting and tracking... When we create a bunch of 'par' sparks, e.g. via a strategy, the expected behaviour is that we get one thread per core that will churn through those sparks, one by one. The one by one is important, each core/cap/hec is only actively evaluating one of these sparks at a time. It's not like we have a thread per spark and they're all evaluating in parallel. The parallelism is limited to the core count (well, cap/hec). However, if each of these sparks makes a safe FFI call then the one-by-one behaviour is broken. Instead we get an OS thread per spark all running concurrently. If one looks at the mechanisms in detail one can see why this happens, but the overall effect can be disastrous for performance. If we have a small number of cores e.g. 8 and a large number of sparks e.g. 1024, then spawning 1024 OS threads each of which has plenty of work to do is not a recipe for good performance. The OS will share the time fairly which means each thread will get terrible CPU cache utilisation. Think of something like big numerical calculations where the cache utilisation is critical: running 100s of OS threads per core doing numerical calculations will be much worse than running one thread that churns through the calculations sequentially. So why does this happen? Well, when a cap is idle the cap's scheduler checks if it has any sparks in its spark pool, or in other cap's spark pools. If there are sparks available it grabs one and starts a Haskell thread to run it. Now the Haskell thread makes a safe FFI call. That means the Haskell thread is put to sleep while the foreign call runs in a new OS thread. But this now means that the scheduler thinks that this cap is idle again (there are no runnable Haskell threads), so it grabs another spark. And so another OS thread gets made to run the FFI call. And again and again, until we've converted all the sparks and forked off loads of OS threads to run these FFI calls. The problem is that the scheduler cannot tell the difference between a safe FFI call that is blocking and taking no CPU time (like waiting on network IO) vs a safe FFI call that is not blocking and is fully utilising the CPU (like big numerical calculations). In the latter case we would really like to say that the cap is not really idle, we don't need to create more work to do. In the former case it's important to create more work to do. But there's no easy way to tell the difference between these two cases, so this is a hard problem to fix. If a programmer knows that this is what is going on then they can work around the problem by being very careful with the number of sparks they make (kind of losing some of the benefits of sparks) or they can make all the expensive FFI calls unsafe (which can be tricky when using reusable FFI binding libs). But in practice most GHC users will never figure out that this is what is happening (plausibly it might be possible from looking at the threadscope view very careful). So that's the conundrum: a problem that users will find hard to identify, and no easy automatic solution. Ho hum. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1
by GHC 14 Nov '15

14 Nov '15

#11085: Relying on the existence of CallStack in 7.10 breaks bootstrappability with 7.10.1 -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D1472 | Wiki Page: -------------------------------------+------------------------------------- 7.10.2 added the CallStack mechanism, and GHC already relies on this while being built. Unfortunately, it is enabled with "GLASGOW_HASKELL >= 710", which also applies to GHC 7.10.1, which does not have CallStack, and fails building the stage-1 compiler because the symbol is not found. This patch makes the CPP directive more strict, requiring more than 7.10 instead of at least. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11085> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10997: Pattern synonym causes Iface error.
by GHC 14 Nov '15

14 Nov '15

#10997: Pattern synonym causes Iface error. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- From the mailing list.. Hello, We have a pattern synonym as follows type family Showable (a :: k) :: Constraint where Showable (a :: *) = (Show a) Showable a = () pattern Just' :: () => (Showable a) => a -> (Maybe a) pattern Just' a <- (extractJust -> (True, a)) where Just' a = Just a When we try to use the pattern in a different package, the error was [1 of 1] Compiling Bar ( Bar.hs, .stack- work/dist/x86_64-linux/Cabal-1.22.4.0/build/Bar.o ) /tmp/test/p2/.stack- work/install/x86_64-linux/lts-3.5/7.10.2/lib/x86_64-linux- ghc-7.10.2/p1-0.1.0.0-I5t4il6dN7vIqsT1XgYsM3/Foo.hi Declaration for Just' Pattern synonym Just': Iface type variable out of scope: k Cannot continue after interface file error The error only occurred when Showable was polykinded and we used synonym in a different package . Using the synonym in the same package works fine. This problem did not happen with the following definition of (non polykinded ) Showable type family Showable a :: Constraint where Showable a = (Show a) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10997> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10667: '-g' option generates invalid assembly when '*/*' operator is used
by GHC 14 Nov '15

14 Nov '15

#10667: '-g' option generates invalid assembly when '*/*' operator is used -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2-rc2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Bug is observed when building cpphs-1.19 {{{#!hs module A where x */* y = 42 }}} {{{ $ ghc -fforce-recomp A -g [1 of 1] Compiling A ( A.hs, A.o ) /tmp/ghc23923_0/ghc_2.s: Assembler messages: /tmp/ghc23923_0/ghc_2.s:17:0: Error: bad expression /tmp/ghc23923_0/ghc_2.s:17:0: Warning: missing operand; zero assumed ... }}} The problem here is the following assembly snippet: {{{ .text .align 8 .loc 1 3 1 /* */* */ .quad 12884901911 .quad 0 .quad 15 }}} Would it be worthwile using ';' as a comment instead? Don't know if it's universally portable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10667> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11064: Call Arity has the trivial application case wrong
by GHC 14 Nov '15

14 Nov '15

#11064: Call Arity has the trivial application case wrong -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- In `e x`, the result of `x` is not shared in contrast to `e (f x)`, where CorePrep will turn it into `let y = f x in e x`. So in {{{ let f = ... in e (f x) }}} we know that f is called at most once, but in {{{ let f = ... in e f }}} we do not know that. Previously Call Arity would assume that in `e x`, `x` is evaluated at most once. This rarely would make a difference (the argument `x` is analized with an incoming arity of 0, so no eta-expansion would be done anyways), but of course this should still be fixed. I just validated a patch and will push shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10690: Save merged signatures to disk
by GHC 14 Nov '15

14 Nov '15

#10690: Save merged signatures to disk -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The Backpack model of development encourages users to mix signatures together. For example: {{{ unit p where signature H where x :: Int unit q where signature H where y :: Int unit r where include p include q module A where import H(x,y) }}} When `A` imports `H`, it should see both `x` and `y` (i.e. a merged version of the two signatures.) There are two possible ways to implement this: 1. The old strategy: When `A` imports `H`, it somehow "sees" both the interface for H from `p`, and the interface from `q`, and it merges them together on-the-fly. 2. The new strategy: Before compiling `A`, we merge the interfaces together, and use that merged interface as what A imports and gets its export from. Strategy (2) has a few advantages: in separate compilation, it avoids the need to repeatedly merge interfaces together, and it also simplifies GHC in that we don't have to manage on the fly signature merging. Now the challenge: GHC currently assumes that every build product is associated with a source file: however, merged interface files don't have this property. Both `--make` and one-shot `-c` compilation infrastructure is organized around this property. Here's is the proposal for how to slot this in: 1. Eliminate `HscSource` distinction between `HsBootFile` and `HsigFile`: the file is always called `A.hs-boot`. Instead, the type checker simply behaves differently depending on whether or not we know what the underlying implementation of `A` is (passed in using the `-sig-of` flag. If we know the underlying implementation is `containers:Data.Map`, we compile the hs-boot file "signature-style", if we don't, we assume it's `this-package:A` and compile it "boot-style" (Conceivably for cross-unit mutual recursion this will need to be more sophisticated, but this will do for now.) By the way, this means that all signature files now compile to A.hi-boot. 2. We introduce a new `HscSource` type, `HsBootMerge`, representing an `hi` (and stub `o`) file that will be generated by a signature merge. Intuitively, this operation will merge together A.hi-boot as well as any signatures which were brought into scope by a `-package` flag. Unlike `HsSrcFile` and `HsBootFile`, `ModSummary`s that are `HsBootMerge` don't have a source file. 3. When compiling `--make`, for all "signature-style" hs-boot files in the module graph, we generate an `HsBootMerge` summary to serve as the `NotBoot` node of that module name. This means if you `import A`, you're actually importing the `HsBootMerge` that produces `A.hi`. 4. When compiling one-shot, we have a new command for generating the `HsBootMerge`: `ghc --merge-requirements A`. This will go and look for an A.hi-boot as well as any external signatures and merge them together. Note that we can't use the existing compilation pipeline `-c` to generate merged hs-boot files, since these presuppose that there is some input source file, which there is none in this case. 5. When generating a Makefile dependency graph, an entry for an `HsBootMerge` looks like this: {{{ A.o : A.hi-boot A.o : /path/to/ghc/foo-0.1/A.hi # if -include-pkg-deps is added }}} That is to say, an `HsBootMerge` looks like a normal source file that imports each signature it's merging together, but doesn't have a source file associated with it. One downside with this representation is that it makes Makefile rules a little more complicated: how do you build `A.o`? Not with `ghc -c A.hs`, but with `ghc --merge-requirements A`. I'm not sure what the best way of solving this is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10690> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10622: Rename Backpack packages to units
by GHC 14 Nov '15

14 Nov '15

#10622: Rename Backpack packages to units -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- After today's weekly Backpack call, we have come to the conclusion that we have two different types of "packages" in the Backpack world: 1. Cabal packages, which have a single `.cabal` file and are a unit of distribution which get uploaded to Hackage, and 2. Backpack packages, of which there may be multiple defined in a Backpack file shipped with a Cabal package; and are the building blocks for modular development in the small. It's really confusing to have both of these called packages: thus, we propose to rename all occurrences of Backpack package to unit. A Cabal package may contain MULTIPLE Cabal units, although old-style Cabal files will only define one unit. Here are some of the consequences: 1. We rename `PackageKey` to `UnitId`, as it identifies a unit rather than a Cabal package. (I think this actually makes the function of these identifiers clearer.) We'll also distinguish Cabal-file level `PackageName`s from Backpack-file `UnitName`s. Finally, any given unit will be uniquely identified by an `InstalledUnitId`. 2. The source-level syntax of Backpack files will use `unit` in place of where `package` was used before. 3. For backwards compatibility reasons, we'll sometimes arrange for `PackageName`/`UnitName` and `InstalledUnitId`/`InstalledPackageId` to coincide. Specifically, the unit of a package which has the same `UnitName` as the `PackageName` is treated specially: its `InstalledUnitId` is guaranteed to be the same as the `InstalledPackageId` and it is what is "visible" when a user uses old concepts such as `-package foo-0.1` to select a package. 4. The installed package database is extended to record some number of units per an installed package: the public facing API is that you can register a package CONTAINING some number of units. For old-style packages, there will be only one unit with a matching `UnitName`, so this will be isomorphic to an old style package; however, GHC will grow some new APIs for selecting specific units to bring into scope. GHC really mostly only cares about units, but if a user asks for a package using, e.g. `-package` it will translate this request into a request for the appropriate unit. 5. For old-style packages, Cabal will continue to write and register a package configuration file which implicitly defines a single unit. However, the plan is to give GHC the capacity to generate unit description files (like package description files, but per unit), which Cabal can interpret and use to register packages in the global database using a `ghc-pkg` which can register units and "unitless" package description files which don't implicitly define a unit. (NB: we must create unit description files, because `ghc-pkg recache` is expected to be able to regenerate the database.) (NB: we want to be able to add units for a package separately, because this is how units for indefinite packages are created as they are instantiated with new implementations.) 6. Cabal could also finally grow the "multiple libraries per single Cabal file" support people have wanted; it's just a stylized use of the Backpack facilities. The work plan: 1. Modify `bin-package-db` to reflect the unit/package split, but otherwise keep ghc-pkg and GHC the same (so old-style package description still supported, and interpreted as a package containing one unit.) Source modifications to GHC assume that a package only has one unit. 2. Generalize GHC to work with packages with multiple units 3. Add capability to Cabal/ghc-pkg to register just units. For compilation of Backpack files, GHC will write out units which Cabal will then install to the real registry 4. Backpack! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13