April 2017 - ghc-tickets

[GHC] #9505: Bounded instance for Word (and possibly others) uses unboxed literals
by GHC 03 Dec '18

03 Dec '18

#9505: Bounded instance for Word (and possibly others) uses unboxed literals -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- There's a comment above saying GHC won't optimise. I think since 7.8 they are unboxed by default, so that comment and the explicit constructors can be removed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9505> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12643: class declaration works in ghci, but not in a file
by GHC 02 Dec '18

02 Dec '18

#12643: class declaration works in ghci, but not in a file -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- The following ghci session prints no errors: {{{ > :set -XStandaloneDeriving -XDeriveGeneric > import GHC.Generics > import Control.Monad.Except > deriving instance Generic (ExceptT e m a) > class F a where f :: Rep (Except String a) x }}} However, when I transfer this to a file: {{{ {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE DeriveGeneric #-} import GHC.Generics import Control.Monad.Except deriving instance Generic (ExceptT e m a) class F a where f :: Rep (Except String a) x }}} I get a mysterious error: {{{ test.hs:6:17: error: • Couldn't match type ‘Rep (Except String a0)’ with ‘Rep (Except String a)’ Expected type: Rep (Except String a) x Actual type: Rep (Except String a0) x NB: ‘Rep’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for ‘f’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: f :: forall a. F a => forall x. Rep (Except String a) x In the class declaration for ‘F’ }}} If I turn on -fdefer-type-errors, I can verify that the type family indeed reduces far enough for a and x to be arguments to injective types, so I believe GHC should not consider this an error: {{{ > :set -XRankNTypes > :kind! forall a x. Rep (Except String a) x forall a x. Rep (Except String a) x :: * = D1 ('MetaData "ExceptT" "Control.Monad.Trans.Except" "transformers-0.5.2.0" 'True) (C1 ('MetaCons "ExceptT" 'PrefixI 'False) (S1 ('MetaSel 'Nothing 'NoSourceUnpackedness 'NoSourceStrictness 'DecidedLazy) (Rec0 (Data.Functor.Identity.Identity (Either [Char] a))))) x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8043: Feature Request : Qualified module exports
by GHC 01 Dec '18

01 Dec '18

#8043: Feature Request : Qualified module exports ------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I quite like the practice of using `-XNoImplicitPrelude` and then defining my own (often per-project) Prelude doing things like: {{{ module MyProject.Prelude ( module P ) import Data.Text as P (Text) import Prelude as P hiding (head, init, tail, last) }}} As an extension to the above idea, I would like to add qualified module exports defined so that I can do this: {{{ module MyProject.Prelude ( module P , qualified module T ) import Data.Text as P (Text) import Prelude as P hiding (head, init, tail, last) import qualified Data.Text as T }}} so that any file which imports `MyProject.Prelude` will then have all the identifiers that they would normally get if they did: {{{ import qualified Data.Text as T }}} Is this something that would have to go through the Haskell Next procedure? If so, how does one get that kicked off? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13535: vector test suite uses excessive memory on GHC 8.2
by GHC 30 Nov '18

30 Nov '18

#13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 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: -------------------------------------+------------------------------------- First noticed [https://github.com/haskell/vector/pull/161#issuecomment-292031845 here]. I haven't managed to boil this down to a test case with no dependencies yet, so for the time being, this requires `vector`. To reproduce, follow these steps: {{{ $ git clone https://github.com/erikd/vector $ cd vector/ $ cabal install --only-dependencies --enable-tests -w /opt/ghc/8.2.1/bin/ghc $ cabal configure --enable-tests -w /opt/ghc/8.2.1/bin/ghc $ cabal test }}} When building `vector-tests-O2`, GHC will stall when compiling the `Tests.Vector` module. On machines with modest memory allowances (e.g., [https://travis-ci.org/haskell/vector/jobs/218749281#L1270 the machines used on Travis CI]), GHC will be killed with an out-of-memory error after trying to compile `Tests.Vector` for a while. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13535> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 61

[GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application
by GHC 30 Nov '18

30 Nov '18

#13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Proprietary application is ran on 44 cores (88 with HT) machine (same problem on 12 core). It is Haskell between wxHaskell (wxWidgets for UI) and C API. It is doing FFI calls most of the time. Calls are not so many, but possibly not so fast. I'm trying to profile where is the problem, in which calls. But very strange behaviour is there. "total time" of application that is running 30secs to 1min is showing 0.33secs. Even MAIN function is not 100%. Please, see first part of .prof file: Tue Mar 28 15:38 2017 Time and Allocation Profiling Report (Final) app.exe +RTS -N -A40m -qb0 -p -RTS total time = 0.33 secs (325 ticks @ 1000 us, 1 processor) total alloc = 86,317,264 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc MAIN MAIN <built- in> 12.6 2.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13492> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8177: Roles for type families
by GHC 29 Nov '18

29 Nov '18

#8177: Roles for type families ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Now that we have [wiki:Roles roles], it might be helpful to be able to give a role signature for a data/type family. At the moment, data/type family constructors have all parameters conservatively assigned to be role `N`. Thus {{{ data family D a -- Parameter conservatively assumed to be N class C a where op :: D a -> a instance C Int where .... newtype N a = MkN a deriving( C ) -- Rejected }}} The generalised-newtype-deriving clause `deriving( C )` is rejected because `D` might use its parameter at role `N` thus: {{{ data instance D [b] = MkD (F b) -- F is a type function }}} It would be strictly more expressive if we could * '''Declare''' the roles of D's arguments (as we can declare their kinds). E.g. {{{ data family D a@R }}} * '''Check''' that each family instance obeys that role signature. E.g. given the preceding role signature, reject this instance: {{{ data instance D [b] = MkD (F b) -- F is a type function }}} I think there is no technical difficulty here. Just a question of doing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 41

[GHC] #12965: String merging broken on Windows
by GHC 26 Nov '18

26 Nov '18

#12965: String merging broken on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- #9577 introduced string literal merging via the linker. Unfortunately I haven't been able to get this to function on Windows, resulting in testsuite failures of #9577. Even `gcc` appears to do the wrong thing here, {{{ $ cat hi.c #include <stdio.h> const char *hi = "hello world"; extern const char *hi2; void main() { printf("%p %p", hi, hi2); } $ cat hi2.c const char *hi2 = "hello world"; $ gcc -c hi.c; gcc -c hi2.c; gcc -fmerge-all-constants hi2.o hi.o $ ./a.exe 0x100403040 0x100403030 $ gcc -s hi2.c $ cat hi2.s .file "hi2.c" .globl hi .section .rdata,"dr" .LC0: .ascii "hello world\0" .data .align 8 hi: .quad .LC0 .ident "GCC: (GNU) 5.3.0" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12965> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13573: Add Foldable1 / Traversable1 to base
by GHC 26 Nov '18

26 Nov '18

#13573: Add Foldable1 / Traversable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #10365 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `NonEmpty` and `Semigroup` are in ''base'' and are on our way to add `Semigroup` as a superclass of `Monoid` (#10365), this is a fine time to ask if we should include [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Foldable.html Foldable1], [https://hackage.haskell.org/package/semigroupoids-5.1/docs/Data- Semigroup-Traversable.html Traversable1] in ''base'' as well. `Foldable` has partial functions already, functions that only make sense for non-empty structures such as `foldr1`, `foldl1`, `minimum` and `maximum`. There are also functions which ''could'' be defined in terms of `Foldable` like `head` / `tail` (for definition of `unimprove` and `Diff` see [https://github.com/ekmett/semigroupoids/issues/49 semigroupoids issue #49] and this [https://github.com/arkeet/difference/blob/0f0e14f51cf1ecd7ebf2d8c52204bd91a… github] page) {{{#!hs minimum1 :: (Ord a, Foldable1 f) => f a -> a minimum1 = S.getMin . foldMap1 S.Min maximum1 :: (Ord a, Foldable1 f) => f a -> a maximum1 = S.getMax . foldMap1 S.Max head1 :: Foldable1 f => f a -> a head1 = S.getFirst . foldMap1 S.First last1 :: Foldable1 f => f a -> a last1 = S.getLast . foldMap1 S.Last foldr1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldr1 f = unimprove . foldMap1 (\a -> Diff (f a) a) foldl1 :: Foldable1 t => (a -> a -> a) -> (t a -> a) foldl1 f = unimprove . getDual . foldMap1 (\a -> Dual $ Diff (flip f a) a) }}} There is also the possibility of adding further functions such as `foldM`, `foldM_`, `foldrM` and `foldlM` for non-empty structures. As usual I don't have more concrete ideas, but let's start by testing the waters before submitting a ghc-proposal. I understand this may be controversial -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #13362: GHC first generation of GC to be as large as largest cache size by default
by GHC 26 Nov '18

26 Nov '18

#13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: numa cache gc | 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 will improve performance a lot by default. If anyone needs different size - there is "-A" RTS option. Machines are very different. Currently this size is 512k by default for all different architectures and hardware no matter what. In most cases machines with larger caches have more RAM as well and vice versa. So this will affect positively both small and larger machines. It will be most efficient in most cases to keep short lived objects in caches. Most modern workstation and server machines have L3 cache as well, that is why I'm asking for "largest cache size". Second idea will be if there are two short lived generations on machines with second and third level caches with sizes that match both. For NUMA machines with non-unified caches (like [http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825 this strange and non-common ARM]) the common solution could be to set first generation to be with size of the largest cache of smallest core. Which will not be the optimal, but close to. [https://www.reddit.com/r/haskell/comments/5rf1r5/ghc_first_generation_of_gc… Related Reddit discussion] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10844: CallStack should not be inlined
by GHC 26 Nov '18

26 Nov '18

#10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | 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 Revisions: | -------------------------------------+------------------------------------- The use of CallStack based error messages (since changeset:6740d70d95cb) has led to some code size increase, and I believe this needs to be improved. While investigating the #10788, I was looking at the core produced by that code, and I found this in the code: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main17 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 100 0}] Main.main17 = unpackCString# "vecto_20t0fI93Jj9LUbaZg6e04I"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main16 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 0}] Main.main16 = unpackCString# "Data.Vector.Primitive.Mutable"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main15 :: [Char] [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 120 0}] Main.main15 = unpackCString# "./Data/Vector/Primitive/Mutable.hs"# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main14 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main14 = I# 97# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main13 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main13 = I# 16# -- RHS size: {terms: 2, types: 0, coercions: 0} Main.main12 :: Int [GblId, Caf=NoCafRefs, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] Main.main12 = I# 21# -- RHS size: {terms: 8, types: 0, coercions: 0} Main.main11 :: SrcLoc [GblId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 80}] Main.main11 = SrcLoc Main.main17 Main.main16 Main.main15 Main.main14 Main.main13 Main.main14 Main.main12 }}} This is clearly a CallStack from a library, and there is no point in copying that into the (every?) use of wherever that came from, as it will only increase code size and slow down compilation. I don’t know how to fix it, though. Float out CallStacks more aggressively? Or is the problem that unfoldings are recorded before that can happen? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10844> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 33