June 2017 - ghc-tickets

[GHC] #13730: Running GLUT code in GHCi yields NSInternalInconsistencyException
by GHC 30 Jun '17

30 Jun '17

#13730: Running GLUT code in GHCi yields NSInternalInconsistencyException ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- I tried running some `GLUT` code in macOS Sierra (Version 10.12.5 (16F73)) and ran into a strange error. If you're willing to use `cabal-install`, you can just do this: {{{ $ cabal install GLFW-0.5.2.5 }}} And run this module in with `runghc`: {{{#!hs -- GLUT.hs module Main where import Graphics.UI.GLUT (($=), getArgsAndInitialize, createWindow, displayCallback, mainLoop) main :: IO () main = do (_progName, _args) <- getArgsAndInitialize _window <- createWindow "Hello World" displayCallback $= return () mainLoop }}} {{{ $ runghc GLUT.hs 2017-05-19 12:03:02.199 ghc[24628:669385] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread! }}} On the other hand, compiling and running the executable works without issue. Alternatively, you can compile the attached files, which require no dependencies: {{{ $ ghc HsGLUT.c GLUT2.hs [1 of 1] Compiling Main ( GLUT2.hs, GLUT2.o ) Linking GLUT2 ... $ ghci HsGLUT.o GLUT2.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/rscott/.ghci [1 of 1] Compiling Main ( GLUT2.hs, interpreted ) Ok, modules loaded: Main. λ> main 2017-05-19 12:06:15.365 ghc[24671:670166] GLUT Fatal Error: internal error: NSInternalInconsistencyException, reason: nextEventMatchingMask should only be called from the Main Thread! }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #4210: LLVM: Dynamic Library Support
by GHC 30 Jun '17

30 Jun '17

#4210: LLVM: Dynamic Library Support -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: feature request | Status: closed Priority: low | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"6171b0b326e52221a0631cf75eb4866b36abe631/ghc" 6171b0b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6171b0b326e52221a0631cf75eb4866b36abe631" configure: Check for binutils #17166 This bug affects bfd ld on ARMv7, causing ld to incorrectly emit R_REL_COPY relocations, breaking tables-next-to-code. We've known about it for several years now and there is not yet a fix upstream. Previously we would simply force use of ld.gold on ARM. However, given the rework of linking configuration, I thought a more principled solution was in order. Test Plan: Validate on armv7 Reviewers: austin, hvr Subscribers: angerman, rwbarton, thomie, erikd GHC Trac Issues: #4210 Differential Revision: https://phabricator.haskell.org/D3676 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4210#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13810: Gold linker fails
by GHC 30 Jun '17

30 Jun '17

#13810: Gold linker fails ----------------------------------------+--------------------------------- Reporter: ksaric | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: linker | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When using gold linker in the project, the compilation fails. The same error occurs even when using nix, without stack. The bug can be reproduced very easily. You can clone from here (https://github.com/ksaric/bronze-linker) and `stack build`. Or you can: - `stack new project` - `cd project` - `stack build` Now it builds. - then add gold flags to cabal like here - https://github.com/ksaric /bronze-linker/blob/master/bronze-linker.cabal#L22-L25 - `stack build` Now it fails. ---- Linking .stack-work/dist/x86_64-linux-nix/Cabal-1.24.2.0/build/bronze- linker-exe/bronze-linker-exe ... /nix/store/x9v0yxy5iybp2m2ccqwqkvxgjy7zrw8f-binutils-2.28/bin/ld.gold: --hash-size=31: unknown option /nix/store/x9v0yxy5iybp2m2ccqwqkvxgjy7zrw8f-binutils-2.28/bin/ld.gold: use the --help option for usage information collect2: error: ld returned 1 exit status 'cc' failed in phase 'Linker'. (Exit code: 1) ---- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13810> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13881: Inexplicable error message when using out-of-scope type variable in pattern type signature
by GHC 29 Jun '17

29 Jun '17

#13881: Inexplicable error message when using out-of-scope type variable in pattern type signature -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code gives an error on any version of GHC since 7.6: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Bug where data family Sing (a :: k) data instance Sing (z :: [a]) where SNil :: Sing '[] SCons :: Sing x -> Sing xs -> Sing (x ': xs) fl :: forall (l :: [a]). Sing l -> Sing l fl (SNil :: Sing (l :: [y])) = SNil fl (SCons x xs) = SCons x xs }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:16:5: error: • The type variable ‘y’ should be bound by the pattern signature ‘Sing l’ but are actually discarded by a type synonym To fix this, expand the type synonym [Note: I hope to lift this restriction in due course] • In the pattern: SNil :: Sing (l :: [y]) In an equation for ‘fl’: fl (SNil :: Sing (l :: [y])) = SNil | 16 | fl (SNil :: Sing (l :: [y])) = SNil | ^^^^^^^^^^^^^^^^^^^^^^^ }}} I can't wrap my head around the error message, though. It complains about a type synonym discarding `y`, but there are no type variables in this program! The //real// source of the issue, the fact that `y` is out of scope (and should actually be `a`), is obscured. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13881> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13879: Strange interaction between higher-rank kinds and type synonyms
by GHC 29 Jun '17

29 Jun '17

#13879: Strange interaction between higher-rank kinds and type synonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code with typechecks with GHC 8.0.1, 8.0.2, 8.2.1, and HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data family Sing (a :: k) data (a :: j) :~~: (b :: k) where HRefl :: a :~~: a data instance Sing (z :: a :~~: b) where SHRefl :: Sing HRefl (%:~~:->) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: a :~~: b) (p :: forall (z :: Type) (y :: z). a :~~: y -> Type). Sing r -> p HRefl -> p r (%:~~:->) SHRefl pHRefl = pHRefl type App f x = f x type HRApp (f :: forall (z :: Type) (y :: z). a :~~: y -> Type) (x :: a :~~: b) = f x }}} Now I want to refactor this so that I use `App`: {{{#!hs (%:~~:->) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: a :~~: b) (p :: forall (z :: Type) (y :: z). a :~~: y -> Type). Sing r -> App p HRefl -> App p r }}} However, GHC doesn't like that: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs -fprint-explicit-kinds -fprint-explicit- foralls GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:21:20: error: • Expected kind ‘(:~~:) j z a a’, but ‘'HRefl j a’ has kind ‘(:~~:) j j a a’ • In the second argument of ‘App’, namely ‘HRefl’ In the type signature: (%:~~:->) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: a :~~: b) (p :: forall (z :: Type) (y :: z). a :~~: y -> Type). Sing r -> App p HRefl -> App p r | 21 | -> App p HRefl | ^^^^^ Bug.hs:22:20: error: • Expected kind ‘(:~~:) j z a b’, but ‘r’ has kind ‘(:~~:) j k a b’ • In the second argument of ‘App’, namely ‘r’ In the type signature: (%:~~:->) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: a :~~: b) (p :: forall (z :: Type) (y :: z). a :~~: y -> Type). Sing r -> App p HRefl -> App p r | 22 | -> App p r | ^ }}} These errors are surprising to me, since it appears that the two higher- rank types, `z` and `y`, are behaving differently here: `y` appears to be willing to unify with other types in applications of `p`, but `z` isn't! I would expect //both// to be willing to unify in applications of `p`. Out of desperation, I tried this other formulation of `(%:~~:->)` which uses `HRApp` instead of `App`: {{{#!hs (%:~~:->) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: a :~~: b) (p :: forall (z :: Type) (y :: z). a :~~: y -> Type). Sing r -> HRApp p HRefl -> HRApp p r }}} But now I get an even stranger error message: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs -fprint-explicit-kinds -fprint-explicit- foralls GHCi, version 8.2.0.20170623: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:21:20: error: • Expected kind ‘forall z (y :: z). (:~~:) j z a y -> *’, but ‘p’ has kind ‘forall z (y :: z). (:~~:) j z a y -> *’ • In the first argument of ‘HRApp’, namely ‘p’ In the type signature: (%:~~:->) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: a :~~: b) (p :: forall (z :: Type) (y :: z). a :~~: y -> Type). Sing r -> HRApp p HRefl -> HRApp p r | 21 | -> HRApp p HRefl | ^ Bug.hs:21:20: error: • Expected kind ‘forall z (y :: z). (:~~:) j z a y -> *’, but ‘p’ has kind ‘forall z (y :: z). (:~~:) j z a y -> *’ • In the first argument of ‘HRApp’, namely ‘p’ In the type signature: (%:~~:->) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: a :~~: b) (p :: forall (z :: Type) (y :: z). a :~~: y -> Type). Sing r -> HRApp p HRefl -> HRApp p r | 21 | -> HRApp p HRefl | ^ Bug.hs:22:20: error: • Expected kind ‘forall z (y :: z). (:~~:) j z a y -> *’, but ‘p’ has kind ‘forall z (y :: z). (:~~:) j z a y -> *’ • In the first argument of ‘HRApp’, namely ‘p’ In the type signature: (%:~~:->) :: forall (j :: Type) (k :: Type) (a :: j) (b :: k) (r :: a :~~: b) (p :: forall (z :: Type) (y :: z). a :~~: y -> Type). Sing r -> HRApp p HRefl -> HRApp p r | 22 | -> HRApp p r | ^ }}} That's right, it can't match the kinds: * `forall z (y :: z). (:~~:) j z a y -> *`, and * `forall z (y :: z). (:~~:) j z a y -> *` Uh... what? Those are the same kind! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13879> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #2988: Improve float-in
by GHC 29 Jun '17

29 Jun '17

#2988: Improve float-in -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: 8.4.1 Component: Compiler | Version: 6.10.1 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 @@ -2,1 +2,1 @@ - {{{ + {{{#!hs @@ -18,1 +18,1 @@ - {{{ + {{{#!hs @@ -26,1 +26,1 @@ - {{{ + {{{#!hs New description: At the moment we can get a cascade of simplifier iterations like this: {{{#!hs let x1 = blah x2 = x1 : [] x3 = 1 : x2 x4 = 2 : x3 in case blah of True -> f x4 False -> g x4 }}} Then `x4` satisfies the conditions for `postInlineUnconditionally` (not top-level, used once in each case branch, not inside lambda). So it's inlined. In the next iteration of the simplifier, `x3` satisfies the conditions, and so on. It might be better for `postUnconditionally` to require an interesting context. But then this case doesn't work so well: {{{#!hs let x = blah in case foo of { A -> ..x..; B -> ..x..; C -> ..no x.. } }}} If C is the hot branch, it's a good idea to push `x` into the A,B branches. But perhaps this question is one that `FloatIn` should deal with, not `postInlineUnconditionally`. Indeed `FloatIn` has the following comment: {{{#!hs -- For case expressions we duplicate the binding if it is -- reasonably small, and if it is not used in all the RHSs -- This is good for situations like -- let x = I# y in -- case e of -- C -> error x -- D -> error x -- E -> ...not mentioning x... }}} So this ticket is just to record the idea: * Make `postInlineUnconditionally` check for interesting context ...and check on performance changes, and whether `FloatIn` is doing the Right Thing. Simon -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2988#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13220: Performance regressions in testsuite from join points
by GHC 29 Jun '17

29 Jun '17

#13220: Performance regressions in testsuite from join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Need to look at, among others: * `perf/compiler/T9961` * `deriving/perf/T10858` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13220> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43

[GHC] #13898: Consolidate treatment of strictness in parser
by GHC 29 Jun '17

29 Jun '17

#13898: Consolidate treatment of strictness in parser -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- Currently GHC's treatment of binding strictness in the Haskell parser and AST is the result of a long, winding evolution. Since Phab:D3670 we have tracked strictness of variable bindings (e.g. `!x = ...`) in the `SrcStrictness` in `FunRhs` (see `Note [Varieties of bindings]`). This is parsed by ``. However, explicitly lazy bindings (e.g. `~x = ...`) are parsed via a completely different means (see the rule starting with `~` in `aexp`) and represented as `ELazyPat` until being mangled into a pattern in `RdrHsSyn`. It seems to me like these two paths should be more symmetric. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13898> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9588: Add `MonadPlus {IO, Either e}` and `Alternative (Either e)` instances
by GHC 29 Jun '17

29 Jun '17

#9588: Add `MonadPlus {IO,Either e}` and `Alternative (Either e)` instances -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following 3 instances are currently Orphans in `transformers` but shall be defined in `base` instead: {{{#!hs instance MonadPlus IO instance MonadPlus (Either e) instance Alterantive (Either e) }}} This proposal by SPJ already passed the CLC back in April and only needs implementing. I'll submit a patch shortly to Phab -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9588> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13890: Loss of inlining after strictness analysis
by GHC 28 Jun '17

28 Jun '17

#13890: Loss of inlining after strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While investigating something else I saw this in the final `Tidy Core` after optimisation {{{ join { wild_X5jU [Dmd=<S,1*U>] :: (# State# RealWorld, Array Int HValue #) [LclId[JoinId(0)], Unf=Unf{Src=InlineStable, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=False) Tmpl= jump $j1_s5RP w_s5Qs}] wild_X5jU = jump $j1_s5RP ww_s5Qw } in jump wild_X5jU; }}} That's ridiculous! Why wasn't it inlined at its (only!) use site? It turns out that * The original `InlineStable` came from when `wild` was lambda-bound. See `Note [Case binders and join points]` in `Simplify.hs` * But then worker-wrapper let-binds that previously-lambda-boudn arg in `WwLib.mkWWstr_one`. But it does not remove the unfolding. That's bad; in contrast, when we beta-reduce we are careful to remove the unfolding; see `Note [Zap unfolding when beta-reducing]` in `Simplify.hs`. * We don't `preInlineUnconditionally` things with stable unfoldings; see `Note [Stable unfoldings and preInlineUnconditionally]` in `SimplUtils` Net result: it doesn't get inlined at all! Easy fix: zap the unfolding in `mkWWstr_one` as well. I'm unhappy with the whole business of passing both boxed and unboxed versions, described in `Note [Case binders and join points]`. It smells wrong, and this ticket is another canary. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13890> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3