April 2018 - ghc-tickets

[GHC] #15082: Split the TrieMap module into a generic and core specific part.
by GHC 05 May '18

05 May '18

#15082: Split the TrieMap module into a generic and core specific part. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4618 | Wiki Page: -------------------------------------+------------------------------------- == Split the module into two parts. Motivation: I came across a situation where I would have liked to make LabelMap a instance of TrieMap. However this would create a transitive dependency on CoreSyn for essentially all Cmm related Modules which seemed excessive. Splitting TrieMap into a general and Core specific part changes this. It also leads to a nicer separation of concerns. I have implemented a first version of this in D4618. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14982: LLVM default -mcpu setting inhibits customization
by GHC 05 May '18

05 May '18

#14982: LLVM default -mcpu setting inhibits customization -------------------------------------+------------------------------------- Reporter: tommd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (LLVM) | 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: -------------------------------------+------------------------------------- With GHC 8.4.1 we are now passing a default `-mcpu` selection to llvm. This default is passed regardless of any explicit command line option such as `-optlc=-mcpu=native`. If/when the user explicitly specifies the architecture we now get a failed build. The error message from LLVM is: {{{ llc: for the -mcpu option: may only occur zero or one times! `llc' failed in phase `LLVM Compiler'. (Exit code: 1) }}} This is when compiling with GHC 8.4.1 as such: {{{ ghc-8.4.1 -fforce-recomp -fllvm -optlc=-mcpu=native -O2 tt.hs }} I suggest we either check for a user option of `mcpu` before adding the default or revert this behavior and allow llvm to take it's (optimistic and less portable) default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8995: When generalising, use levels rather than global tyvars
by GHC 05 May '18

05 May '18

#8995: When generalising, use levels rather than global tyvars ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- A long time ago Didier Remy described how to use 'ranks' or 'levels' to make the test "is this type variable free in the environment" when generalising a type. Oleg gives a [http://okmij.org/ftp/ML/generalization.html great explanation here]. GHC still uses the old "find the free type variables in the environment" method. But in fact GHC ''does'' maintain levels, just as Didier explains. The level is called `Untouchables` and is used to make sure we don't infer non-principal types for things involving GADTs. The same level stuff is used to prevent skolem-escape. Details with `Note [Untouchable type variables]` and `Note [Skolem escape prevention]` in `TcType`. So it ought to be straightforward to use the same levels for generalisation. I had a go, and came across the following tricky points: * We need to bump the level (`pushUntouchables`) when starting to typecheck a let RHS. Currently we don't. That will be a bit less efficient, because we'll end up deferring unification constraints that currently get solved immediately. * However the current set up is actually wrong. In particular, we generate a constraint where the implications do not have monotonically increasing level numbers (invariant `(ImplicInv)` in `TcType`). Try this program with `-ddump-tc-trace`. {{{ {-# LANGUAGE GADTs #-} module Bar where data T where MkT :: a -> (a->Int) -> T f x z = case x of MkT _ _ -> let g y = (y, [z,Nothing]) in (g True, g 'c') }}} I don't know how to make this bug cause an actual problem, but it's very unsettling. Bumping the level before doing the RHS would solve this. * Once we have bumped the level, we then have to do some more type- variable promotion, especially of type variables free in the finally- chosen type of the binder. This came out rather awkwardly in the code. * Because we now get more deferred equality constraints, there's a real risk that we'll end up quantifying over them. If we get, say `(gbl ~ Maybe lcl)`, where `gbl` is a type var free in the envt, we '''do not''' want to quantify over it! (It would be sound, but would lead to horrible types.) A long time ago Didier Remy described how to use 'ranks' or 'levels' to make the test "is this type variable free in the environment" when generalising a type. Oleg gives a [http://okmij.org/ftp/ML/generalization.html great explanation here]. GHC still uses the old "find the free type variables in the environment" method. But in fact GHC ''does'' maintain levels, just as Didier explains. The level is called `Untouchables` and is used to make sure we don't infer non-principal types for things involving GADTs. The same level stuff is used to prevent skolem-escape. Details with `Note [Untouchable type variables]` and `Note [Skolem escape prevention]` in `TcType`. So it ought to be straightforward to use the same levels for generalisation. I had a go, and came across the following tricky points: * We need to bump the level (`pushUntouchables`) when starting to typecheck a let RHS. Currently we don't. That will be a bit less efficient, because we'll end up deferring unification constraints that currently get solved immediately. * However the current set up is actually wrong. In particular, we generate a constraint where the implications do not have monotonically increasing level numbers (invariant `(ImplicInv)` in `TcType`). Try this program with `-ddump-tc-trace`. {{{ {-# LANGUAGE ExistentialQuantification #-} module Bar where data T = forall a. MkT a f x z = case x of MkT y -> let g y = [y,Nothing] in g True }}} Look for the `reportUnsolved` trace and you'll nested implications, both with level 1. I don't know how to make this bug cause an actual problem, but it's very unsettling. Bumping the level before doing the RHS would solve this. * Once we have bumped the level, we then have to do some more type- variable promotion, especially of type variables free in the finally- chosen type of the binder. This came out rather awkwardly in the code. * Because we now get more deferred equality constraints, there's a real risk that we'll end up quantifying over them. If we get, say `(gbl ~ Maybe lcl)`, where `gbl` is a type var free in the envt, we '''do not''' want to quantify over it! (It would be sound, but would lead to horrible types.) Rather we want to promote `lcl`, and not quantify. Currently we don't get many deferred equality constraints, becuase they all get done "on the fly". But if we do get one, we do quantify over it, which yields a rather stupid type. Try this: {{{ {-# LANGUAGE ExistentialQuantification #-} module Bar where data T = forall a. MkT a f x z = case x of MkT _ -> let g y = [z,Nothing] in (g True, g 'c') }}} We get this `g :: forall t a2. Maybe a ~ Maybe a2 => t -> [Maybe a2]`, where `x::a` is in the envt. Not very clever! This only shows up with existentials and In general I think we want to find all the type variables reachable by equality constraints from the environment, and not quantify over them. * We also use the type environment `getGlobalTyVars` in ''kind'' generalisation, and kind inference currently does not use the untoucahble story. Adapting it to use levels might be tricky because we currently assume we solve all kind equality constraints on-the-fly, and don't gather any deferreed constraints. Maybe it's easy, but needs thought. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10572: Template Haskell does not implicitly quantify types
by GHC 04 May '18

04 May '18

#10572: Template Haskell does not implicitly quantify types -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider the simple quasiquoter producing a type variable: {{{ tv :: QuasiQuoter tv = QuasiQuoter { quoteType = varT . mkName } }}} If a type variable is introduced elsewhere in a type signature, it is implicitly quantified as normal and the TH name resolves properly: {{{ id' :: a -> [tv|a|] id' x = x }}} But if the type variable is not mentioned elsewhere in the type, an error results: {{{ const' :: a -> [tv|b|] -> a const' x _ = x }}} {{{ Not in scope: type variable ‘b’ }}} One would expect the type variable introduced by the TH splice to be included in the implicit quantification of the type signature. In fact, there is no way to introduce a new type variable in this context, apart from using {{{Rank(2/N)Types}}} with an explicit {{{forall}}}. But this prevents the type variable from being referred to elsewhere in the type, eg: {{{ const'' :: [tv|a|] -> b -> [tv|a|] const'' x _ = x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10572> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15093: Testsuite should output JUnit XML for better CircleCI support
by GHC 03 May '18

03 May '18

#15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: CI | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment when builds are run on CircleCI, failures are not reported in any special way. This means you have to download the build log to see the bottom of the testing phase as it is too long to see in the browser. Instead, you can output the test results as JUnit XML which then CircleCI can slurp up and present nicely. https://circleci.com/docs/2.0 /configuration-reference/#store_test_results There is a python library which makes it easy to generate this output. https://github.com/kyrus/python-junit-xml Even better, an actual python testing library could be used which could automatically output this information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15093> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper
by GHC 03 May '18

03 May '18

#15049: NUMA not detected on Win10 with AMD Ryzen Threadripper --------------------------------------+--------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- AMD's Threadripper can be configured to be a 1-socket 2-die NUMA system: Coreinfo.exe: {{{ Logical to Physical Processor Map: **------------------------------ Physical Processor 0 (Hyperthreaded) --**---------------------------- Physical Processor 1 (Hyperthreaded) ----**-------------------------- Physical Processor 2 (Hyperthreaded) ------**------------------------ Physical Processor 3 (Hyperthreaded) --------**---------------------- Physical Processor 4 (Hyperthreaded) ----------**-------------------- Physical Processor 5 (Hyperthreaded) ------------**------------------ Physical Processor 6 (Hyperthreaded) --------------**---------------- Physical Processor 7 (Hyperthreaded) ----------------**-------------- Physical Processor 8 (Hyperthreaded) ------------------**------------ Physical Processor 9 (Hyperthreaded) --------------------**---------- Physical Processor 10 (Hyperthreaded) ----------------------**-------- Physical Processor 11 (Hyperthreaded) ------------------------**------ Physical Processor 12 (Hyperthreaded) --------------------------**---- Physical Processor 13 (Hyperthreaded) ----------------------------**-- Physical Processor 14 (Hyperthreaded) ------------------------------** Physical Processor 15 (Hyperthreaded) Logical Processor to Socket Map: ******************************** Socket 0 Logical Processor to NUMA Node Map: ****************---------------- NUMA Node 0 ----------------**************** NUMA Node 1 Approximate Cross-NUMA Node Access Cost (relative to fastest): 00 01 00: 1.0 1.4 01: 1.7 1.2 }}} However, ghc-8.4.1 doesn't detect the NUMA topology when running with `--numa` {{{ ghc.EXE: --numa: OS reports NUMA is not available }}} I haven't attempted dualbooting into Linux, yet, so I can't tell whether it's a Windows-only issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14956: NUMA not detected on Aarch64 NUMA machine
by GHC 03 May '18

03 May '18

#14956: NUMA not detected on Aarch64 NUMA machine --------------------------------------+--------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- {{{ # lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 96 On-line CPU(s) list: 0-95 Thread(s) per core: 1 Core(s) per socket: 48 Socket(s): 2 NUMA node(s): 2 L1d cache: 32K L1i cache: 78K L2 cache: 16384K NUMA node0 CPU(s): 0-47 NUMA node1 CPU(s): 48-95 # ./cgraytrace_prof_thread +RTS -s -A40m -qn24 --numa cgraytrace_prof_thread: --numa: OS reports NUMA is not available cgraytrace_prof_thread: cgraytrace_prof_thread: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args> ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9113: Template Haskell should warn about non-exhaustive pattern matches
by GHC 03 May '18

03 May '18

#9113: Template Haskell should warn about non-exhaustive pattern matches -------------------------+------------------------------------------------- Reporter: tvh | Owner: Type: bug | Status: new Priority: | Milestone: normal | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Template Haskell | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- When using Typed Template Haskell, There are no warings for non-exhaustive patterns inside the quote. {{{ {-# LANGUAGE TemplateHaskell #-} module Foo where import Language.Haskell.TH.Lib foo :: Maybe Int -> TExpQ Bool foo x = [||case x of Nothing -> False||] }}} Instead the warnings appear where the code is spliced. {{{ {-# LANGUAGE TemplateHaskell #-} module Bar where import Foo x = $$(foo (Just 1)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9113> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies
by GHC 03 May '18

03 May '18

#8970: Non-exhaustive pattern match warning with DataKinds and TypeFamilies ------------------------------------+------------------------------------- Reporter: tensor5 | 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: | ------------------------------------+------------------------------------- The code is: {{{ data K = Foo | Bar data D1 :: K -> * where F1 :: D1 Foo B1 :: D1 Bar class C (a :: K -> *) where data D2 a :: K -> * foo :: a k -> D2 a k -> Bool instance C D1 where data D2 D1 k where F2 :: D2 D1 Foo B2 :: D2 D1 Bar foo F1 F2 = True foo B1 B2 = True }}} With -Wall it gives the warning: {{{ Test.hs:23:5: Warning: Pattern match(es) are non-exhaustive In an equation for `foo': Patterns not matched: F1 B2 B1 F2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8853: Alarming looking warning about non-exhaustive pattern
by GHC 03 May '18

03 May '18

#8853: Alarming looking warning about non-exhaustive pattern -------------------------+------------------------------------------------- Reporter: | Owner: MikolajKonarski | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc2 normal | Operating System: Linux Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: x86_64 (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- The attached code produces this alarming warning: ~/waste$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.0.20140228 ~/waste$ ghc -Wall --make AlarmingPattern.hs -fforce-recomp [1 of 1] Compiling Main ( AlarmingPattern.hs, AlarmingPattern.o ) AlarmingPattern.hs:6:7: Warning: Pattern match(es) are non-exhaustive In an equation for ‘takeFromInv’: Patterns not matched: (GHC.Types.I# _) (GHC.Types.I# (#x)) with #x `notElem` [0#] Linking AlarmingPattern ... ~/waste$ ./AlarmingPattern AlarmingPattern: AlarmingPattern.hs:(6,7)-(7,26): Non-exhaustive patterns in function takeFromInv -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7