February 2019 - ghc-tickets

[GHC] #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin)
by GHC 27 Feb '19

27 Feb '19

#15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) -------------------------------------+------------------------------------- Reporter: cmal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: randomRIO | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- randomRIO (1,100) ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): nameModule system $dShow_a78p Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15755> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16080: runTestTT from ghci caused a panic.
by GHC 27 Feb '19

27 Feb '19

#16080: runTestTT from ghci caused a panic. -------------------------------------+------------------------------------- Reporter: | Owner: (none) emacstheviking | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Inside a REPL within Emacs+Intero-mode, running a stack project. I am writing a simple lexer for fun and I decided to try to see why I wasn't getting expected behaviour from an HUnit function. {{{ runTestTT classificationTests ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-linux): nameModule system $dShow_a5Xw Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16080> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs.
by GHC 27 Feb '19

27 Feb '19

#16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. -------------------------------------+------------------------------------- Reporter: hanrai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: getCurrentDirectory | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got this message when I type 'getCurrentDirectory' in repl in spacemacs. ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-mingw32): nameModule system $dShow_adyn Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler\basicTypes\Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16088> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16367: Panic when trying to openFile
by GHC 27 Feb '19

27 Feb '19

#16367: Panic when trying to openFile --------------------------------------+---------------------------------- Reporter: vilem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- {{{ $ stack repl Note: No local targets specified, so a plain ghci will be started with no package hiding or package options. If you want to use package hiding and options, then you can try one of the following: * If you want to start a different project configuration than /Users/vl200/.stack/global-project/stack.yaml, then you can use stack init to create a new stack.yaml for the packages in the current directory. * If you want to use the project configuration at /Users/vl200/.stack/global-project/stack.yaml, then you can add to its 'packages' field. Configuring GHCi with the following packages: GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/vl200/.ghci Loaded GHCi configuration from /private/var/folders/km/1g5b7h891674vhv9z1g4d9cw0000gn/T/haskell-stack- ghci/2a3bbd58/ghci-script Prelude> import System.IO Prelude System.IO> openFile ".g .granule .gitignore .ghc .ghci .gitconfig Prelude System.IO> openFile ".granule" Re Read ReadMode ReadS ReadWriteMode Real RealFloat RealFrac RelativeSeek Prelude System.IO> openFile ".granule" ReadMode ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): nameModule system $dShow_a1QJ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug}}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16356: Unexpected type application in default declaration
by GHC 27 Feb '19

27 Feb '19

#16356: Unexpected type application in default declaration -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (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: -------------------------------------+------------------------------------- All of these work: {{{#!hs {-# LANGUAGE PolyKinds, TypeApplications, TypeFamilies, FlexibleInstances #-} import Data.Kind (Type) data B (a :: k) type family FClosed :: k -> Type where FClosed @k = B @k type family FOpen :: k -> Type type instance FOpen @k = B @k class FAssocClass k where type FAssoc :: k -> Type instance FAssocClass k where type FAssoc @k = B @k }}} This one doesn't: {{{#!hs class FAssocDefaultClass k where type FAssocDefault :: k -> Type type FAssocDefault @k = B @k }}} {{{ A.hs:21:23: error: Unexpected type application @k In the default declaration for ‘FAssocDefault’ | 21 | type FAssocDefault @k = B @k | }}} So, what are the rules of the game? Let's fix this and document in the User's Guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16356> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16369: Implement testing of stage1 in ./validate --hadrian
by GHC 27 Feb '19

27 Feb '19

#16369: Implement testing of stage1 in ./validate --hadrian -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: task | Status: new Priority: high | Milestone: Component: Build System | Version: 8.7 (Hadrian) | 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 `master` doesn't support `./validate --hadrian` yet, most of that patch is ready in [https://gitlab.haskell.org/ghc/ghc/merge_requests/326 !326] and will be split up in a few MRs to make review & landing easier. However, it doesn't yet implement testing of the stage 1 compiler, just stage 2. This ticket serves as a reminder to implement testing of stage 1 with hadrian in the validate script. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16354: LLVM Backend generates invalid assembly.
by GHC 26 Feb '19

26 Feb '19

#16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.9 (LLVM) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ #!haskell module Main where import System.Random import qualified Data.Vector as V g1 = mkStdGen 0 :: StdGen v2 = take 10000 $ randoms g1 :: [Int] main :: IO () main = do undefined }}} {{{ $ /e/ghc_regSpill/inplace/bin/ghc-stage2.exe Repro.hs -O2 -fllvm -O2 Loaded package environment from C:\ghc\msys64\home\Andi\tmp\minmax\unpred\.ghc.environment.x86_64-mingw32-8.7.20190215 [1 of 1] Compiling Main ( Repro.hs, Repro.o ) C:\\ghc\\msys64\\tmp\\ghc385768_0\\ghc_6.s: Assembler messages: C:\\ghc\\msys64\\tmp\\ghc385768_0\\ghc_6.s:354: Error: junk at end of line, first unrecognized character is `,' `gcc.exe' failed in phase `Assembler'. (Exit code: 1) }}} I've reproduced this with ghc 8.4/8.6 and HEAD using llvm 7.0.1 on windows. It only occurs with -O2. The issues arise from these directives: {{{ .section .rdata,"dr",discard,__xmm@000000000000004e0000000000000000 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16354> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15463: "Serious" validation failures on i686
by GHC 26 Feb '19

26 Feb '19

#15463: "Serious" validation failures on i686 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: T3171, | Blocked By: heapprof001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A very recent run of `./validate` on i686 revealed 6 failures, 4 of which I'm hopefully fixing with [https://phabricator.haskell.org/D5031 D5031], but the other two look more serious. The circle ci build logs are here: https://circleci.com/gh/ghc/ghc/7578 One of the remaining failures in particular seems somewhat critical: {{{ Wrong exit code for heapprof001(prof_hc_hb)(expected 0 , actual 139 ) Stdout ( heapprof001 ): a <= a <= a <= a <= a <= a <= a <= Stderr ( heapprof001 ): Segmentation fault *** unexpected failure for heapprof001(prof_hc_hb) }}} While the other one might be a lot simpler: {{{ Actual stdout output differs from expected: --- ./ghci/should_run/T3171.run/T3171.stdout.normalised 2018-07-31 05:27:01.821192706 +0000 +++ ./ghci/should_run/T3171.run/T3171.run.stdout.normalised 2018-07-31 05:27:01.821192706 +0000 @@ -1 +0,0 @@ -Interrupted. *** unexpected failure for T3171(normal) }}} I have not investigated any of those yet, but the first one does seem like a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15463> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #16366: Strict version of `foldlM`.
by GHC 26 Feb '19

26 Feb '19

#16366: Strict version of `foldlM`. -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 libraries/base | 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: -------------------------------------+------------------------------------- `Data.Foldable.foldlM` is lazy on the accumulation parameter. A user can define {{{foldlM (\acc x -> acc `seq` step acc x) z xs}}}, but actually this function is NOT strict! It is simplified to the following core: {{{#!hs foldlM (\acc x -> acc `seq` step acc x) z xs == go xs z where go [] acc = pure acc go (x:xs) acc = (acc `seq` step acc x) >>= go xs }}} DemandAnalysis infers that `go` is lazy on the second argument because `pure` is lazy in general (e.g. `IO` Monad). Thus `foldlM'` is needed. Its definition would be: {{{#!hs foldlM' :: (Monad m, Foldable t) => (b -> a -> m b) -> b -> t a -> m b foldlM' f z0 xs = foldr c (\x -> x `seq` pure x) xs z0 where c x k = \z -> z `seq` (f z x >>= k) {-# INLINE c #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16366> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation.
by GHC 26 Feb '19

26 Feb '19

#16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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 bug occurs if I define an instance for a typeclass adding a TypeError constraint on the instance, and then I try to derive that instance using Deriving Via in combination with StandaloneDeriving. This is the shortest example I was able to come up with: {{{ {-# Language DataKinds, UndecidableInstances, StandaloneDeriving, DerivingVia #-} import GHC.TypeLits newtype NotNum a = NotNum a instance (TypeError (Text "Not a num")) => Num (NotNum a) where data Foo = Foo deriving via (NotNum Foo) instance Num Foo }}} In this case, it'll fail in compilation with 'Not a Num'. This only seems to happen when combining deriving via with standalone deriving, because if I derive the class like: {{{ data Foo = Foo deriving Num via (NotNum Foo) }}} It works as expected (doesn't fail with my custom error until I actually try to use a Foo where I should use a Num) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7