August 2016 - ghc-tickets

[GHC] #11466: Constraint synonym with Implicit Parameter
by GHC 23 Aug '16

23 Aug '16

#11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- This: {{{ {-# LANGUAGE ConstraintKinds, ImplicitParams #-} module Foo where type Foo = ?foo::() }}} gives {{{ Foo.hs:3:1: error: • Illegal implicit parameter ‘?foo::()’ • In the type synonym declaration for ‘Foo’ }}} in GHC HEAD. It used to work in GHC-7.10. Did not check GHC-8.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11466> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell
by GHC 23 Aug '16

23 Aug '16

#12527: GHC segfault while linking llvm-general while compiling a file using Template Haskell -------------------------------------+------------------------------------- Reporter: HMPerson1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I have a file {{{#!hs -- Lib.hs module Lib where [d| foo = 1 |] }}} and I add `llvm-general` as a dependency, compiling with -v yields the attached log, followed by `segmentation fault (core dumped)`. Investigating with gdb, the back trace is {{{ ... Loading package llvm-general-3.5.1.2 ... linking ... Thread 1 "ghc" received signal SIGSEGV, Segmentation fault. 0x000000004490f604 in ?? () (gdb) bt #0 0x000000004490f604 in ?? () #1 0x0000000044a8798d in ?? () #2 0x0000000000000132 in ?? () #3 0x0000000044a98b38 in ?? () #4 0x0000000044a87b30 in ?? () #5 0x00007fffeed667b1 in ocRunInit_ELF (oc=0xf7f520) at rts/Linker.c:6198 #6 resolveObjs_ () at rts/Linker.c:3196 #7 resolveObjs () at rts/Linker.c:3218 #8 0x00007ffff5eb03a3 in ?? () from /home/michael/.stack/programs/x86_64-linux/ghc-7.10.3/lib/ghc-7.10.3/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/libHSghc-7.10.3 -0AG9TOjDEtx4Ji3wSwHOBe-ghc7.10.3.so #9 0x0000000000000000 in ?? () }}} Note that without the quasi-quotation in `Lib.hs` it will compile fine, and without the `llvm-general` dependency it will also compile fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12528: ghc: panic! while cimpiling
by GHC 23 Aug '16

23 Aug '16

#12528: ghc: panic! while cimpiling -------------------------------------+------------------------------------- Reporter: nek0 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building one of my projects, GHC crashes with the following message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Block [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The project I'm trying to build can be found at https://github.com/nek0/eidolon. The file it crashes at is called `Foundation.hs` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12528> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11068: Make Generic/Generic1 methods inlinable
by GHC 23 Aug '16

23 Aug '16

#11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | 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): D1447 | Wiki Page: -------------------------------------+------------------------------------- Efficient code generation with GHC.Generics relies on the optimizer being able to completely remove the generic representation of a type. Marking these methods as inlinable ensures that this will be possible even for larger types. I'm working on techniques for transforming generically derived lenses and traversals which rely on taking advantage of the Functor and Applicative laws. This patch supports that work. https://github.com/glguy/generic-traverse -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11702: Constant folding on 'mod/Word' - incorrect result
by GHC 23 Aug '16

23 Aug '16

#11702: Constant folding on 'mod/Word' - incorrect result -------------------------------------+------------------------------------- Reporter: ondrap | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Prelude | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this with GHC 7.10.3 on both MacOS and Linux with '-O' producess results '5 0'. {{{#!hs module Main where testfn :: Word -> IO () testfn wseq = do print $ wseq `mod` 1 main = do testfn 5 print $ (5 :: Word) `mod` 1 }}} Changing type to Int produces correct result. It has probably something to do with compiler/prelude/PrelRules.hs - the rules for Int and Word differ. It seems to me that it should be optimized the same way, but the culprit seems to be the 'rightIdentityDynFlags onew' - that seems to be a clear bug (if it does what I think it does). {{{#!hs primOpRules nm IntRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (intOp2 rem) , leftZero zeroi , do l <- getLiteral 1 dflags <- getDynFlags guard (l == onei dflags) retLit zeroi , equalArgs >> retLit zeroi , equalArgs >> retLit zeroi ] primOpRules nm WordRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (wordOp2 rem) , rightIdentityDynFlags onew ] }}} I found it in different code where lots of inlining reduced some branch of code into this and produced wrong result. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11702> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12492: internal error: allocation of 1048608 bytes too large
by GHC 23 Aug '16

23 Aug '16

#12492: internal error: allocation of 1048608 bytes too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime | Version: 8.0.1 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: -------------------------------------+------------------------------------- I'm getting this error error when trying to use the `ghc-datasize` package from Hackage to calculate the in memory size of a data structure. The full error is: {{{ load-test: internal error: allocation of 1048608 bytes too large (GHC should have complained at compile-time) (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} However, this message is bogus because this is not a static data structure known at compile time, but data loaded from disk. Currently, my test program just loads this complex data structure (about 27 megabytes of CSV with embedded JSON on disk) into memory and then calls `recursiveSize` from `GHC.Datasize` on it. I get this same error message with both ghc7.10.3 and ghc-8.0.1. If I remove the call to `recursiveSize` there is no error. If I `Control.Deepseq.force` the data structures before calling `recursiveSize` there is no error. So, who is to blame? `ghc-datasize` is just Haskell code that calls public APIs so I think the blame lies with GHC. I'll work on getting a small re-producable test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12492> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 23 Aug '16

23 Aug '16

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @simonpj the .gitmodules changes are because the diff on phabricator includes changes to submodules, and to avoid having to push to the upstream for those submodules it's necessary to fork the repos and point the .gitmodules file at your fork for the purposes of uploading the patch to phabricator. The idea is that before pushing the final patch, you revert the .gitmodules changes and push the necessary submodule changes to the relevant upstream repos. I've been encouraging @bgamari and @austin to document this (slightly complex) workflow on the wiki, it really needs to go here: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12520: Segfault when using unboxed tuples in GHCi
by GHC 23 Aug '16

23 Aug '16

#12520: Segfault when using unboxed tuples in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you put this module in a package: {{{#!hs {-# LANGUAGE MagicHash, UnboxedTuples #-} module Bug ( box, wrap, proxy ) where import GHC.Prim box :: (# Proxy# a, b #) -> b box (# x, y #) = y wrap :: b -> Proxy# a -> (# Proxy# a, b #) wrap x = \i# -> (# i#, x #) proxy :: () -> Proxy# a proxy () = proxy# }}} Then in GHCi you can do: {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import Bug Prelude Bug> box (wrap "foo" (proxy ())) "Segmentation fault (core dumped) }}} Alternatively you can crash `runhaskell` if you put the above code in main. It seems that GHCi fails to pickup usage of (# VoidRep, PtrLiftedRep #) tuples or something. The same trick works with `State#` in place of `Proxy#`, but not with `Int#`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12520> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12035: hs-boot knot tying insufficient for ghc --make
by GHC 22 Aug '16

22 Aug '16

#12035: hs-boot knot tying insufficient for ghc --make -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: hs-boot | Operating System: Unknown/Multiple backpack | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC in one-shot mode goes through great pains to make sure that if we are typechecking A.hs with an A.hs-boot, any references to A in the interfaces we load in should point to the `TyThing`s from our LOCAL `tcg_type_env` (`_var`), not the declarations from the `hs-boot`. Indeed, it is never right to load the hi-boot file into the EPS (#10182, #10336). Because in one-shot compilation we are loading things into the EPS anew, there is not much risk of having stale `TyThing`s lying around which still refer to the old `hs-boot` ModDetails. `ghc --make` does not do a sufficient job as knot tying. Specifically, any `Id`s/`TyThing`s from the HPT which were built against the `hs-boot` ModDetails will have out-of-date information. We do manage to tie the knot if we use `tcLookupGlobal` directly, which does look in the local type environment (e.g., #12034 affects both `-c` and `--make`), but if we get our hands on a `TyThing` indirectly, we're in trouble. The case where this is most obvious is unfoldings; see #10083 for an example of GHC behaving differently between `-c` and `--make` (although, ironically, `--make`s bad behavior masks the bug). It's not entirely clear how to fix this problem. In analogy to what happens in `-c`, we should clear the stale `TyThing`s from our HPT and retypecheck them after we have setup the type environment for our `hs` file. But presently in `--make` we don't lazily load types from our home package. Maybe we should! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12381: Type family not reduced
by GHC 22 Aug '16

22 Aug '16

#12381: Type family not reduced -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Andres pointed out that the following fails to compile with GHC 8.0.1 but succeeds with `master` (f53d761df9762232b54ec57a950d301011cd21f8), {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies #-} module Kinds where import GHC.Types type family G (a :: Type) :: Type type instance G Int = Bool type family F (a :: Type) :: G a type instance F Int = True }}} Error: {{{ Hi.hs:10:23: error: • Expected kind ‘G Int’, but ‘'True’ has kind ‘Bool’ • In the type ‘True’ In the type instance declaration for ‘F’ }}} We should figure out what fixed this so it can hopefully be merged for 8.0.2. I initially suspected the patch cited in #12175 but sadly this doesn't seem to be the case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12381> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6