December 2015 - ghc-tickets

[GHC] #9034: GHCi panics when given C++ object file on GNU/Linux
by GHC 08 Jun '16

08 Jun '16

#9034: GHCi panics when given C++ object file on GNU/Linux ------------------------------------------+------------------------------- Reporter: jun0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: panic, dynamic linking | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------------+------------------------------- When given a C++ object file, GHCi panics saying that it can't find standard C++ symbols the object file relies on. If foo.cc contains {{{#!C++ #include <iostream> extern "C" void foo () { std::cout << "bar"; } }}} and is compiled with {{{ g++ -fPIC -c -o foo.o foo.cc }}} then {{{ ghci foo.o -lstdc++ }}} fails with {{{ GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) foo.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc14109_0/ghc14109_1.so: undefined symbol: _ZSt4cout Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It makes no difference to add -L<C++ library paths> which was, IIRC, necessary in older versions of GHC. This applies to only GHCi with C++ -- GHC can link C++ object files just fine, while GHCi has no trouble loading C object files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9034> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #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

[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

[GHC] #9224: Add support for binary integer literals
by GHC 27 May '16

27 May '16

#9224: Add support for binary integer literals -------------------------------------------+------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: Keywords: literals | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Currently, Haskell98/2010 support base-10, base-8 (via `0[oO]`-prefix) and base-16 (via `0[xX]`-prefix) integer literals. I hereby propose to add conditional support for base-2 integers via a `0[bB]`-prefix, controlled via a new `-XBinaryLiterals` language extension flag/pragma. The change to the lexer is trivial (see attached patch), however I'm stuck on the lexer using a 32-bit feature-mask, of which all 32bits are already taken, and I'd need a 33th bit for the `BinaryLiteralsBit` flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9051: Report heap profile data in eventlog
by GHC 27 May '16

27 May '16

#9051: Report heap profile data in eventlog ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It would be useful if heap profile data could be reported in the eventlog (either by assigning samples with IDs and recording the sample in the eventlog, or putting the entire profile information in the eventlog). This would make it easier to correlate heap profile data with other events reported by the RTS. It may be hard to stuff the entire sample in the eventlog because the sample is arbitrary size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10604: Make Generic1 kind polymorphic
by GHC 27 May '16

27 May '16

#10604: Make Generic1 kind polymorphic -------------------------------------+------------------------------------- Reporter: | Owner: ekmett DerekElkins | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: low | Operating System: Unknown/Multiple Component: Core | Type of failure: None/Unknown Libraries | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It looks to me that the Generic1 class (and the Rep1 associated type) can immediately be generalized to forall k. k -> *. If k was instantiated to anything other than *, you wouldn't be able to make an instance for Par1, but then I don't think it would ever come up so that would be exactly the right behavior. This allows, in particular, DataKinds to be used as a parameter to instances of Generic1. I don't know if this would affect deriving, but I wouldn't really expect it to. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10604> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9399: CPP does not process test case enum01.hs correctly
by GHC 25 May '16

25 May '16

#9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: cpp | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: enum01.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The printTest cpp macro does not seem to be being applied in the test suite test enum01.hs (libraries/base) {{{ > ghci -cpp enum01.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( enum01.hs, interpreted ) enum01.hs:91:3: Not in scope: ‘printTest’ enum01.hs:92:3: Not in scope: ‘printTest’ : }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18