- ghc-tickets - Haskell.org

[GHC] #13202: Levity polymorphism panic in GHCi
by GHC 22 Mar '17

22 Mar '17

#13202: Levity polymorphism panic in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- With current `master`, {{{ $ ghci GHCi, version 8.1.20170126: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ben/.ghci λ> import GHC.Exts λ> :set -XTypeApplications -XMagicHash -XTypeInType λ> data TypeRep (a :: k) = TypeRep λ> let typeRepKind = undefined :: TypeRep (a :: k) -> TypeRep k λ> let typeRep = undefined :: TypeRep (a :: k) λ> let x = typeRepKind (typeRep @(Maybe Int#)) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20170126 for x86_64-unknown-linux): isUnliftedType forall (a :: TYPE q). a :: TYPE q Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1869:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13413: GHC HEAD panic: collectNBinders
by GHC 22 Mar '17

22 Mar '17

#13413: GHC HEAD panic: collectNBinders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: JoinPoints | 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: -------------------------------------+------------------------------------- `repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this issue. Trying to build it leads to several `collectNBinders` panics is various modules. You can reproduce this by compiling this module: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} module Data.Repa.Eval.Generic.Seq.Chunked where import GHC.Exts (Int#, (+#), (*#), (>=#)) ------------------------------------------------------------------------------- -- | Fill a block in a rank-2 array, sequentially. -- -- * Blockwise filling can be more cache-efficient than linear filling for -- rank-2 arrays. -- -- * The block is filled in row major order from top to bottom. -- fillBlock2 :: (Int# -> a -> IO ()) -- ^ Update function to write into result buffer. -> (Int# -> Int# -> a) -- ^ Function to get the value at an (x, y) index. -> Int# -- ^ Width of the whole array. -> Int# -- ^ x0 lower left corner of block to fill. -> Int# -- ^ y0 -> Int# -- ^ w0 width of block to fill -> Int# -- ^ h0 height of block to fill -> IO () fillBlock2 write getElem !imageWidth !x0 !y0 !w0 h0 = do fillBlock y0 ix0 where !x1 = x0 +# w0 !y1 = y0 +# h0 !ix0 = x0 +# (y0 *# imageWidth) {-# INLINE fillBlock #-} fillBlock !y !ix | 1# <- y >=# y1 = return () | otherwise = do fillLine1 x0 ix fillBlock (y +# 1#) (ix +# imageWidth) where {-# INLINE fillLine1 #-} fillLine1 !x !ix' | 1# <- x >=# x1 = return () | otherwise = do write ix' (getElem x y) fillLine1 (x +# 1#) (ix' +# 1#) {-# INLINE [0] fillBlock2 #-} }}} This compiles on GHC 8.0.2, but on GHC HEAD: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs [1 of 1] Compiling Data.Repa.Eval.Generic.Seq.Chunked ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170201 for x86_64-unknown-linux): collectNBinders 2 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1179:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1183:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:1970:25 in ghc:CoreSyn }}} Interestingly, compiling this triggers the panic at any optimization level, but loading the module into GHCi does not cause it to panic. This regression was introduced in 8d5cf8bf584fd4849917c29d82dcf46ee75dd035 (Join points). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13464: Pattern match checker runs even when not needed
by GHC 21 Mar '17

21 Mar '17

#13464: Pattern match checker runs even when not needed -------------------------------------+------------------------------------- Reporter: jstolarek | 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: -------------------------------------+------------------------------------- I have code that triggers pattern match checker warning: {{{ Pattern match checker exceeded (2000000) iterations in a case alternative. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) }}} I would like to silence that warning. Alas, `-Wno-incomplete-patterns` does nothing - the warning still appears. I would expect that if I do not want to check for incomplete patterns then pattern match checker is not run at all and thus does not exceed maximum number of iterations! I can only use `-w` to silence all the warnings but this is an overkill - definitely not what I want. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13464> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13462: stack upgrade failed, version 1.0.4 at macosx
by GHC 21 Mar '17

21 Mar '17

#13462: stack upgrade failed, version 1.0.4 at macosx -------------------------------------+------------------------------------- Reporter: chinaxing | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: panic | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- os: Darwin lambda-cat.local 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64 macOS sierra, 10.12.3 stack version: Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64 ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/79/l2kk9s8572gdvzc8r5jq2pf40000gn/T/ghc39735_0/libghc_68.dylib, 5): no suitable image found. Did find: /var/folders/79/l2kk9s8572gdvzc8r5jq2pf40000gn/T/ghc39735_0/libghc_68.dylib: malformed mach-o: load commands size (50048) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 28 action(s). -- While building package stack-1.4.0 using: /private/var/folders/79/l2kk9s8572gdvzc8r5jq2pf40000gn/T/stack- upgrade36593/stack-1.4.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/13462> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9701: GADTs not specialized properly
by GHC 21 Mar '17

21 Mar '17

#9701: GADTs not specialized properly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This has probably been raised before, but I can't find a ticket. If I write {{{#!hs data Silly a where Silly :: Ord a => a -> Silly a isItSilly :: a -> Silly a -> Bool isItSilly a (Silly x) = a < x isItSillyInt :: Int -> Silly Int -> Bool isItSillyInt = isItSilly }}} then I get {{{ isItSilly isItSilly = \ @ a_aBq eta_B2 eta1_B1 -> case eta1_B1 of _ { Silly $dOrd_aBs x_aAy -> < $dOrd_aBs eta_B2 x_aAy } isItSillyInt isItSillyInt = isItSilly }}} Although GHC knows that `eta_B2` is an `Int`, and `x_aAy` therefore must be one as well, it looks up the `<` method in the `eta1_B1` dictionary instead of just using `ltInt`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #13424: readMutVar# is marked can_fail
by GHC 21 Mar '17

21 Mar '17

#13424: readMutVar# is marked can_fail -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `readMutVar#` can only fail if its argument is not a valid pointer. As far as I know, we never check whether a pointer is valid; we ensure it's valid by construction. So I think we should set `can_fail = False`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13424> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8751: Show parenthesised output of expressions in ghci
by GHC 21 Mar '17

21 Mar '17

#8751: Show parenthesised output of expressions in ghci ------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- Operator fixity can be a source of bugs (even for experienced users!),[#point1 (1)] precedence levels may vary between languages and then there are user-defined operators. Attached is a patch for a ghci command allowing users to quickly parenthesise expressions as a sanity check (and as an alternative to using :info and parsing the result yourself). The command itself is activated with `:paren`: {{{ ghci> :paren 2 + 10 * 4 / 3 2 + ((10 * 4) / 3) ghci> :paren \a b → a == b || b && a == (b == a) || b \ a b -> (a == b) || ((b && (a == (b == a))) || b) ghci> :paren 5 + 1 `mod` 2 5 + (1 `mod` 2) ghci> :paren 5 * 1 `mod` 2 (5 * 1) `mod` 2 }}} A friend of mine also pointed out that this could eventually be integrated into `haskell-mode` where the user could temporarily replace an expression with a parenthesised version or have different colours indicate different levels of logical nesting. [=#point1 (1)] [http://www.knosof.co.uk/cbook/accu06.html Developer beliefs about binary operator precedence] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8751> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #13461: Panic on compile of file with a hole, importing a module with a lot of identifiers
by GHC 21 Mar '17

21 Mar '17

#13461: Panic on compile of file with a hole, importing a module with a lot of identifiers -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So I was trying to test the performance of `validSubstitutions`, I generated a file with a lot of identifiers, and compiled it with my current GHC, `The Glorious Glasgow Haskell Compilation System, version 8.0.2`. The example was very simple, just: {{{ import ManyIds test :: Int -> Int test = _ }}} Where `ManyIds.hs` was generated with the python script: {{{ print("module ManyIds where") print() for i in range(10000): print("a{} :: Int -> Int".format(i)) print("a{} _ = {}".format(i,i)) print() }}} i.e. it has a lot of identifiers of the form {{{ ... a1337 :: Int -> Int a1337 _ = 1337 a1338 :: Int -> Int a1338 _ = 1338 ... }}} The error I got was: {{{ [2 of 2] Compiling Main ( manyIdsTest.hs, manyIdsTest.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] __a5IO :: t_a5IN[tau:1] (CHoleCan: _)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 20 Mar '17

20 Mar '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > it fails to transform some cases I would like it to. Can you give some specific programs that you would like to be optimised and aren't? A list of specific examples would help to make sure that everyone on this thread was talking about the same things. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:70> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows
by GHC 20 Mar '17

20 Mar '17

#13431: Linker error related to atan and ntdll on 32-bit Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: GHC rejects | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- That's a somewhat confusing title, so let me explain in more detail what I mean. I first noticed this issue when someone [https://github.com/idris-lang /Idris-dev/pull/3684 couldn't build Idris] on 32-bit Windows (using GHC 7.8, 7.10, or 8.0). Trying to link the Idris executable resulted in this cryptic linker error: {{{ Preprocessing executable 'idris' for idris-0.99.1... [1 of 1] Compiling Main ( main\Main.hs, dist\build\idris \idris-tmp\Main.o ) Linking dist\build\idris\idris.exe ... C:/Users/RyanGlScott/Software/ghc-8.0.1-x86/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(dohds01059.o):(.idata$5+0x0): multiple definition of `_imp__atan' C:/Users/RyanGlScott/Software/ghc-8.0.1-x86/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/libntdll.a(dgjjs01967.o):(.idata$5+0x0): first defined here collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) }}} The culprit was apparently Idris's dependency on the `mintty` package. The important bit was that `mintty` lists `ntdll` as in the `extra-libraries` stanza of its `.cabal` file. As it turns out, you can also reproduce this with a more recent version of `Win32`, which also depends on `ntdll`. First, run these steps: {{{ $ cabal get Win32 $ cd Win32-2.5.2.0/ $ cabal sandbox init $ cabal install . -w $(pwd)/../../../../Software/ghc-8.0.1-x86/bin/ghc }}} This will install the recent `Win32-2.5.2.0` in a sandbox (NB: I'm using 32-bit Windows GHC 8.0.1 here). Now create this file (which I named `Bug.hs`): {{{ module Main (main) where main :: IO () main = print (atan 0.5 :: Double) }}} And you can reproduce the linker error like so: {{{ $ ../../../../Software/ghc-8.0.1-x86/bin/ghc Bug.hs -package-db .cabal- sandbox/i386-windows-ghc-8.0.1-packages.conf.d/ -package Win32 -fforce- recomp [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug.exe ... C:/Users/RyanGlScott/Software/ghc-8.0.1-x86/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/libmsvcrt.a(dohds01059.o):(.idata$5+0x0): multiple definition of `_imp__atan' C:/Users/RyanGlScott/Software/ghc-8.0.1-x86/mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../i686-w64-mingw32/lib/../lib/libntdll.a(dgjjs01967.o):(.idata$5+0x0): first defined here collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) }}} It's important to use 32-bit Windows GHC here, since I am unable to reproduce this with 64-bit Windows GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8