December 2016 - ghc-tickets

[GHC] #13022: Pattern Synonyms using other synonyms causes ghc panic
by GHC 21 Dec '16

21 Dec '16

#13022: Pattern Synonyms using other synonyms causes ghc panic -------------------------------------+------------------------------------- Reporter: AveryGlitch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a (somewhat) minimal example: {{{#!hs {-# LANGUAGE PatternSynonyms #-} data Some = Thing Int Int pattern A x = Thing x 0 pattern B x = Thing x 1 pattern C x = Thing x 2 pattern D = C 3 }}} And here's what happened when I tried to load this into ghci: {{{ *Main> :l ghc_bug.hs [1 of 1] Compiling Main ( ghc_bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): kindPrimRep.go rep_a3fP Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12444: Regression: panic! on inaccessible code with constraint
by GHC 21 Dec '16

21 Dec '16

#12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Running the following program with ghci-8.0.1: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Prove where data Nat = Zero | Succ Nat data SNat (n :: Nat) where SZero :: SNat Zero SSucc :: SNat n -> SNat (Succ n) type family (:+:) (a :: Nat) (b :: Nat) :: Nat where m :+: Zero = m m :+: (Succ n) = Succ (m :+: n) sadd :: ((Succ n1 :+: n) ~ Succ (n1 :+: n), (Succ n1) ~ m) => SNat m -> SNat n -> SNat (m :+: n) sadd SZero n = n }}} -ddump-tc-trace shows: {{{ ... dischargeFmv s_a9qV[fuv:4] = t_a9qW[tau:5] (1 kicked out) doTopReactFunEq (occurs) old_ev: [D] _ :: ((n1_a9qu[sk] :+: 'Succ s_a9qV[fuv:4]) :: Nat) GHC.Prim.~# (s_a9qV[fuv:4] :: Nat)ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): ctEvCoercion [D] _ :: (t_a9qW[tau:5] :: Nat) ~# ('Succ (n1_a9qu[sk] :+: s_a9qV[fuv:4]) :: Nat) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It is rightly rejected by ghci-7.10.2: {{{ Prove.hs:42:6: Couldn't match type ‘'Succ n1’ with ‘'Zero’ Inaccessible code in a pattern with constructor SZero :: SNat 'Zero, in an equation for ‘sadd’ In the pattern: SZero In an equation for ‘sadd’: sadd SZero n = n Failed, modules loaded: none. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12444> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13020: Use a fixed SDK for Mac OS X builds
by GHC 21 Dec '16

21 Dec '16

#13020: Use a fixed SDK for Mac OS X builds -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apple releases new systems with new SDK versions. Official documentation says that it is enough to use newest SDK with MACOSX_TARGET set to lowest supported version of Mac OS X. This is not always true, as they try to keep all new features conditionally included, but they sometimes fail. For example `/usr/include/sys/mman.h` file has been changed between SDK10.10 and SDK10.11 without any compatibility flags and resulted in #13005 (Mac OSX uses `MAP_ANON` in place of `MAP_ANONYMOUS`). The solution is: - download the lowest supported SDK from https://github.com/phracker /MacOSX-SDKs - set the path using -isysroot param to gcc Overall would be best to compile using all supported SDKs, but given lack of CI machines I think it is better to build with minimum version. Apple is pretty good at keeping backward compatibility on source level. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13020> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13019: 'stack upgrade' failed with the message "ghc: panic! (the 'impossible' happened)"
by GHC 21 Dec '16

21 Dec '16

#13019: 'stack upgrade' failed with the message "ghc: panic! (the 'impossible' happened)" -------------------------------------+------------------------------------- Reporter: welf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: stack upgrade | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- MacBook Pro, MacOS Sierra 10.12.2 $ stack upgrade Fetched package index. http-client-0.5.3.3: configure http-client-0.5.3.3: build pid1-0.1.0.0: configure pid1-0.1.0.0: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build text-metrics-0.1.0: configure pid1-0.1.0.0: copy/register text-metrics-0.1.0: build aeson-1.0.2.1: configure aeson-1.0.2.1: build th-orphans-0.13.1: configure text-metrics-0.1.0: copy/register th-orphans-0.13.1: build store-core-0.3: configure store-core-0.3: build store-core-0.3: copy/register th-orphans-0.13.1: copy/register th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build optparse-applicative-0.13.0.0: copy/register optparse-simple-0.0.3: configure optparse-simple-0.0.3: build optparse-simple-0.0.3: copy/register http-client-0.5.3.3: copy/register http-client-tls-0.3.3: configure http-client-tls-0.3.3: build th-utilities-0.2.0.1: copy/register store-0.3: configure store-0.3: build http-client-tls-0.3.3: copy/register store-0.3: copy/register aeson-1.0.2.1: copy/register binary-tagged-0.1.4.1: configure binary-tagged-0.1.4.1: build yaml-0.8.20: configure yaml-0.8.20: build path-0.5.9: configure path-0.5.9: build aeson-compat-0.3.6: configure aeson-compat-0.3.6: build http-conduit-2.2.3: configure http-conduit-2.2.3: build persistent-2.6: configure path-0.5.9: copy/register persistent-2.6: build path-io-1.1.0: configure aeson-compat-0.3.6: copy/register path-io-1.1.0: build binary-tagged-0.1.4.1: copy/register http-conduit-2.2.3: copy/register path-io-1.1.0: copy/register yaml-0.8.20: copy/register hpack-0.15.0: configure hpack-0.15.0: build persistent-2.6: copy/register persistent-template-2.5.1.6: configure persistent-template-2.5.1.6: build persistent-sqlite-2.6: configure hpack-0.15.0: copy/register persistent-sqlite-2.6: build persistent-template-2.5.1.6: copy/register persistent-sqlite-2.6: copy/register stack-1.3.0: configure [1 of 1] Compiling Main ( /private/var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/stack- upgrade83426/stack-1.3.0/Setup.hs, /private/v ar/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/stack- upgrade83426/stack-1.3.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/stack- upgrade83426/stack-1.3.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/s etup ... Configuring stack-1.3.0... stack-1.3.0: build Preprocessing library stack-1.3.0... [ 1 of 121] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/buil d/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 121] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 3 of 121] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 4 of 121] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Pro cess/PagerEditor.o ) [ 5 of 121] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 6 of 121] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cab al-1.22.5.0/build/Paths_stack.o ) [ 7 of 121] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 8 of 121] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 9 of 121] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/ghc85411_0/libghc_57.dylib, 5): no suitable image found. Did find: /var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/ghc85411_0/libghc_57.dylib: malformed mach-o: load commands size (47464) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 22 action(s). -- While building package stack-1.3.0 using: /private/var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/stack- upgrade83426/stack-1.3.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13019> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13015: Remove as much Haskell code as we can from Lexer.x
by GHC 20 Dec '16

20 Dec '16

#13015: Remove as much Haskell code as we can from Lexer.x -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- I want to reduce the code in Lexer.x so (1) when I use hasktags I jump to some real source, not the postprocess output, and (2) so that I can avoid suppressing warnings on our Haskell source code, and not just the lexer code. If we are willing to introduce an hs-boot file with the following signatures: {{{ bol :: Int layout :: Int layout_do :: Int layout_if :: Int layout_left :: Int option_prags :: Int }}} We can do quite well; the only functions we can't extract are: begin, pop, multiline_doc_comment, lineCommentToken, nested_doc_comment, withLexedDocType, do_bol, setLine, setFile, warnTab, addTabWarning, lexer, lexTokenAlr, lexToken, lexTokenStream, linePrags, fileHeaderPrags, ignoredPrags, oneWordPrags, twoWordPrags, dispatch_pragmas and known_pragma. Some of these, like lexToken, we can't expect to be able to move to a separate file, as they depend on Alex generated data types and functions (AlexRoutine, alexScanUser). But if we boot-ify lexToken, we can move even more code out. One question, however, is the performance cost of going through an hs-boot file, as these don't inline. I think the constants are fairly safe (inlining opportunities should only occur when we compile Lexer.x, at which point we will have unfoldings for them), but I am less certain about lexToken. Any advice? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13015> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13012: ApiAnnotations comments are not machine checked
by GHC 20 Dec '16

20 Dec '16

#13012: ApiAnnotations comments are not machine checked -------------------------------------+------------------------------------- Reporter: ezyang | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Sprinkled throughout the codebase are comments like this: {{{ -- | let(rec) -- -- - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnLet', -- 'ApiAnnotation.AnnOpen' @'{'@, -- 'ApiAnnotation.AnnClose' @'}'@,'ApiAnnotation.AnnIn' }}} The comments are intended to describe the set of annotations that might be possibly associated with an AST node of this constructor. However, the source of truth about these comments is the Parser itself. It's not difficult to imagine that these comments might get out of date if changes are made to the Parser. Nor does the comment in `ApiAnnotations` nor the wiki page (https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations) explain what the comments are for, and I only recently figured out what they actually mean. (I'm working on a doc patch to improve this.) Ideally, the set of permissible annotations would be encoded in *machine- readable* form, as a contract that we can use to check that the parser upholds the contract. Here is my suggestion: we create a function to recursively traverse a parsed module, and verify that the only annotations associated with any given SrcSpan are the "valid" ones for that AST element. We can enable this extra pass as an "annotation lint" and turn it on for all tests in the test suite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6087: Join points need strictness analysis
by GHC 20 Dec '16

20 Dec '16

#6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6087#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5302: Unused arguments in join points
by GHC 20 Dec '16

20 Dec '16

#5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5302#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12996: Memory leak in recursion when switching from -O1 to -O2
by GHC 20 Dec '16

20 Dec '16

#12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Memory leak, | Operating System: Unknown/Multiple optimization | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For example code see attachment. When compiling with -O1 the code behaves as expected with each loop taking about the same amount of time. At -O2 each iteration takes (nonlinear) more time than the last and leaks memory. It gets slow enough that I never bothered to let it run past 40 iterations since the slowdown seems to be exponential. I initially hit the bug in code using a Set instead of list but turns out the issue can be reduced to an example with lists. Removing either filter, pattern matching or changing the loop fixes the issue. I tested it under the following conditions: * Compiler flags: -fno-full-laziness/No flags * Compiler versions: GHC 8.0.1 and 7.10.3e * Operating Systems: Windows 10, Linux Mint In every case -O1 works as expected with -O2 showing exponential slowdown with each iteration. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors
by GHC 20 Dec '16

20 Dec '16

#13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Keywords: | 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: -------------------------------------+------------------------------------- I think (but I'm not sure) that the following code should type check. This will require using the 'vector' package to illustrate this issue, sorry I couldn't create an example without it. Either uncommenting the explicit `m ()` signature or changing the type to the simpler `D m` data type will allow the code to compile. {{{ {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE KindSignatures #-} import Data.Vector.Unboxed.Mutable (MVector) import Control.Monad.Primitive (PrimMonad, PrimState) data D (x :: * -> *) type T m = MVector (PrimState m) Int --type T m = D m h :: forall m. PrimMonad m => T m -> m () h x = let f _ = (let ?v = x in g) {- :: m () -} in f undefined g :: (PrimMonad m , ?v :: T m) => m () g = undefined main = pure () }}} Alternatively, including `g` into the let binding as opposed to the top level will also compile: {{{ {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE KindSignatures #-} import Data.Vector.Unboxed.Mutable (MVector) import Control.Monad.Primitive (PrimMonad, PrimState) data D (x :: * -> *) type T m = MVector (PrimState m) Int --type T m = D m h :: forall m. PrimMonad m => T m -> m () h x = let f _ = (let ?v = x in g) {- :: m () -} g :: (PrimMonad m , ?v :: T m) => m () g = undefined in f undefined main = pure () }}} Perhaps this isn't a bug and has to do with the rank-2 type inside of Vector, but I'm just putting in this bug report to confirm. This is an issue as of 8.0.2-rc2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13006> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7