March 2017 - ghc-tickets

[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 20 Mar '17

20 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

Re: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows
by GHC 20 Mar '17

20 Mar '17

#2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11394, #13440 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #11394 => #11394, #13440 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2189#comment:52> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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 akio): Replying to [comment:68 simonpj]: > Akio, I've fixed that wrapper issue. Thank you! > > What's next on this ticket? After rebasing the branch on top of your fix, the nofib improvements are again consistent but very small: {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- hpg +0.2% -1.1% 0.212 0.212 0.0% infer +0.3% -1.2% 0.054 0.054 0.0% solid +0.3% -6.6% 0.181 0.181 0.0% sphere +0.3% -1.7% 0.086 0.086 0.0% -------------------------------------------------------------------------------- Min +0.2% -6.6% -23.2% -23.4% -19.2% Max +0.7% +0.1% +16.3% +16.2% 0.0% Geometric Mean +0.3% -0.1% -0.1% -0.1% -0.3% }}} The branch can perform nested CPR in simple cases, but it fails to transform some cases I would like it to. Currently I'm trying to make `extendSigsWithLam` a bit more aggressive by allowing it to generate nested CPR information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:69> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13459: sdist make target doesn't create required ghc-tarballs dir
by GHC 20 Mar '17

20 Mar '17

#13459: sdist make target doesn't create required ghc-tarballs dir -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Build System | Version: 8.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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12518: Allow customizing immutable package dbs by stacking
by GHC 19 Mar '17

19 Mar '17

#12518: Allow customizing immutable package dbs by stacking -------------------------------------+------------------------------------- Reporter: harendra | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 8.0.1 system | 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: -------------------------------------+------------------------------------- = Package Selection Across Multiple Package DBs = As explained by ezyang, when there are multiple package dbs, GHC chooses the packages to use in the following manner. I might have misunderstood so please correct me if I am wrong. * If there are multiple packages with different versions the latest non- broken version is chosen. * If the there are multiple packages with the same version the behavior is unspecified. * If there are multiple packages with the same package-id (shadowing) then the one which comes first in `GHC_PACKAGE_PATH` or which comes first on command line (`-package` flag) will be used. = The Problem = The build tool `Stack` implements stacked package databases. It uses a base package database and then stacks another package database on top of it to customise it further without modifying. The behavior is such that the package db on top of the stack completely overrides the ones below. That means you choose a package from top of the stack even if the version is older. Stack implements this by passing explicit package-ids of the packages to GHC. This scheme works well for cabal projects where we know ALL the packages used by the project in advance. But it does not work for scripts run using runghc. In that case we do not know the packages required by the script in advance and therefore cannot pass the package-ids to GHC. That means we cannot make GHC use the packages in the right way. GHC will choose the latest version even though we want it to choose a possibly older version from the top of the db stack. = Proposed Solution = Implement a new CLI option, something like `--stacked-pkg-dbs`. If this option is used GHC will use `GHC_PACKAGE_PATH` or the -package-db options as a stack of dbs. The first db in the path or the first CLI option will be considered the top of the stack. GHC will choose a package from the first db from the top of the stack irrespective of the version of the package. If the package is broken it should report error rather than silently choosing from the next db. This will allow us to modify an immutable package db by stacking another db on top. Implementing this as a separate option will keep the existing behavior so as to remain backward compatible. This has been discussed in a stack issue on github [https://github.com/commercialhaskell/stack/issues/1957 here]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12