May 2016 - ghc-tickets

[GHC] #10565: GHC 7.10.2 RC: the impossible happened on hPDB-examples-1.2.0.2
by GHC 05 Jun '16

05 Jun '16

#10565: GHC 7.10.2 RC: the impossible happened on hPDB-examples-1.2.0.2 -----------------------------------------+--------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.2-rc1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------------+--------------------------------- When compiling with the RC for Stackage, I get: {{{ [1 of 1] Compiling Main ( examples/Rg.hs, dist/build/Rg/Rg- tmp/Main.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.1.20150619 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone bindIO 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: 19573 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10565> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11816: Refactor SymbolInfo out of Linker.c
by GHC 04 Jun '16

04 Jun '16

#11816: Refactor SymbolInfo out of Linker.c -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11223 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #11223 added a type `SymbolInfo` to `ObjectCode`. This is adding a larger memory overhead to the RTS then need by. `SymbolInfo` is used to determine if a symbol is weak or not. This information can be moved into it's own structure inside `ObjectCode` like a map. Since the majority of the symbols will not be weak this map should be fairly small. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11816> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12138: Simplifier ticks exhausted at compiling svg-builder
by GHC 04 Jun '16

04 Jun '16

#12138: Simplifier ticks exhausted at compiling svg-builder -------------------------------------+------------------------------------- Reporter: JanUlrich | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tried to install svg-builder by "cabal install svg-builder"and got the following error: Resolving dependencies... Configuring svg-builder-0.1.0.1... Building svg-builder-0.1.0.1... Preprocessing library svg-builder-0.1.0.1... [1 of 5] Compiling Graphics.Svg.Path ( src/Graphics/Svg/Path.hs, dist/build/Graphics/Svg/Path.o ) [2 of 5] Compiling Graphics.Svg.Core ( src/Graphics/Svg/Core.hs, dist/build/Graphics/Svg/Core.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone base:Foreign.Storable.$fStorableWord21{v r2cT} [gid] 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: 34200 I tried again with ghc -fsimpl-tick-factor=300 and it worked. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12138> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12129: Optimize the implementation of minusInteger in the integer-gmp package
by GHC 04 Jun '16

04 Jun '16

#12129: Optimize the implementation of minusInteger in the integer-gmp package -------------------------------------+------------------------------------- Reporter: admock | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As mentioned in [https://www.fpcomplete.com/blog/2016/05/weigh-package] the current implementation of `minusInteger` is {{{#!hs minusInteger x y = inline plusInteger x (inline negateInteger y) }}} which always allocates an additional integer. This could be improved by not always calling `negateInteger` and instead having an implementation more like `plusInteger`'s. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12059: Add primop to query for pinned-ness of a ByteArray
by GHC 04 Jun '16

04 Jun '16

#12059: Add primop to query for pinned-ness of a ByteArray -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- It would be useful to have, {{{#!hs isPinnedByteArray# :: MutableByteArray# -> Int# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11223: Dynamic linker on Windows is unable to link against libmingwex
by GHC 03 Jun '16

03 Jun '16

#11223: Dynamic linker on Windows is unable to link against libmingwex -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 7.10.3 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #10726 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The runtime linker seems to be re-exporting some of the symbols of `libmingwex` from the rts archive (using `SymI_HasProto`). Only a very small subset of symbols are re-exporting. If a symbol is needed that isn't re-exported (e.g. `log1p`) then this code can't be run in GHCi because it will result in a duplicate symbols error. A workaround The `rts` seems to be a special case again. The linker seems to ignore the `extra-libraries` from the `package.conf`, which explains why you can put anything you want in there and it'll still compile. {{{ 128 emptyPLS :: DynFlags -> PersistentLinkerState 129 emptyPLS _ = PersistentLinkerState { 130 closure_env = emptyNameEnv, 131 itbl_env = emptyNameEnv, 132 pkgs_loaded = init_pkgs, 133 bcos_loaded = [], 134 objs_loaded = [], 135 temp_sos = [] } 136 137 -- Packages that don't need loading, because the compiler 138 -- shares them with the interpreted program. 139 -- 140 -- The linker's symbol table is populated with RTS symbols using an 141 -- explicit list. See rts/Linker.c for details. 142 where init_pkgs = [rtsUnitId] }}} I've tried 2 approaches which haven't worked completely: 1. I tried removing the symbols from the export list and adding `libmingwex` to the rts's `package.conf`and have it just link against it. But turns out the `rts`'s `package.conf` is ignored on all platforms. I didn't want to have to make an exception for Windows here and I don't know why the other platforms also ignore it so I abandoned this approach. 2. I tried marking the symbols we're re-exporting as weak symbols, so there wouldn't be a change to existing code and would allow you to link against `libmingwex`. But unfortunately because of when the other libraries specified by `-l` are linked in, some of the symbols have already been used and thus aren't weak anymore. So I still get duplicate link errors. What I want to try now is leaving them as weak symbols, but loading `libmingwex.a` at `rts` initialization time. Much like how `kernel32` is loaded. This is hopefully early enough that the symbols haven't been used yet. Example (LogFloat.hs file): {{{#!hs module Main (main) where import Data.Number.LogFloat (log1p) main :: IO () main = print $ log1p 1.0 }}} `runGhc LogFloat.hs` will fail: {{{ Loading package logfloat-0.13.3.3 ... linking ... LogFloat.hs: ...\x86_64-windows- ghc-7.11.20151123\logfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn\HSlogfloat-0.13.3.3-4JZYNCXKwghOD60rvMUAcn.o: unknown symbol `log1p' LogFloat.hs: LogFloat.hs: unable to load package `logfloat-0.13.3.3' }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted
by GHC 02 Jun '16

02 Jun '16

#10852: ghc 7.8.4 on arm - panic: Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: | Owner: andrewufrank | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- i tried to compile (cabal install) chatter-0.5.2.0 on a armbian (debian jessie, with ghc 7.10.2-1 from testing, running on a cubietruck ARMHF Cortex A20) and get in file NLP.Corpora.Conll a panic: [ 9 of 23] Compiling NLP.Corpora.Conll ( src/NLP/Corpora/Conll.hs, dist/build/NLP/Corpora/Conll.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for arm-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fGSerialize:*:_$s<$> 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: 2748218 i do not notice anything particular in the code, except a very long data type with enumerated values. I tried with a higher value for tick-factor (1000) with no improvement. i will now try to run 7.10.2-2 from experimental. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #9766: Use TypeLits in the meta-data encoding of GHC.Generics
by GHC 02 Jun '16

02 Jun '16

#9766: Use TypeLits in the meta-data encoding of GHC.Generics -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 9043 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This ticket serves to track the task of improving the meta-data representation in GHC.Generics as described in the following wiki page: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/GenericDeriving#A… I'm working on this in branch `wip/GenericsMetaData`, and I intend to have it in 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #7105: Better names for derived SCCs of instances
by GHC 30 May '16

30 May '16

#7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11543 | Differential Rev(s): Phab:D2282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D2282 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7105#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11120: Missing type representations
by GHC 29 May '16

29 May '16

#11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 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 Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DataKinds #-} module Bug where import Data.Typeable foo = typeRep (Proxy :: Proxy '[]) }}} I get {{{ GHC error in desugarer lookup in Bug: Can't find interface-file declaration for variable tc'[] Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20151120 for x86_64-apple-darwin): initDs IOEnv failure }}} And I think there may be more trouble. Below are notes I have written to ghc-devs: ------------------------------ I'm a bit confused by the new handling of `Typeable`. 1. You say (in `Note [Grand plan for Typeable]`) that there is trouble making the `TyCon`/`Module` information for the types in `GHC.Types`. But what precisely goes wrong? I agree that it seems a bit fishy, but I don't actually see the spot where trouble lurks. Did you try this? 2. Even more bizarre would be putting `TyCon`/`Module` info for `GHC.Prim` stuff (I'm thinking about the super-magical `TYPE` from my branch) right in `GHC.Prim`. But still I can't quite articulate what goes wrong. There is no Prim.hi file that would be wonky. And, provided that `GHC.Types` itself doesn't try to solve a `Typeable` constraint, no one would ever notice the weird dependency. I recognize that this means we'd have to build the info somewhere manually in GHC, but I don't think that would be too hard -- and I think easier than the current story around name-mangling just so that you can write the typereps by hand in `Data.Typeable.Internal`. There's also not very many lifted tycons in `GHC.Prim`. I count `TYPE` and `RealWorld`, and that's it. For what it's worth, a weird dependency from `GHC.Prim` to `GHC.Types` actually works in practice. I put `Levity` in `GHC.Types` but `TYPE :: Levity -> TYPE 'Lifted` in `GHC.Prim`. No one complained. 3. Let's assume that we really can't clean up this mess. It still seems that several `TyCon`s are missing from `Data.Typeable.Internal`. Like promoted nil and cons, and `Nat`, and `Symbol`. At the least, we should put a loud comment in the export list of `GHC.Types` saying that everything defined there must be accompanied by a definition in `Data.Typeable.Internal`. 4. `Data.Typeable.Internal` uses `mkGhcTypesTyCon`, which refers to `GHC.Types`. But this function is used also for things from `GHC.Prim`, like `(->)`. Solving `Typeable (->)` works fine. But I'm sure there's trouble lurking here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 56