- ghc-tickets - Haskell.org

[GHC] #14490: TTG Snags
by GHC 01 Dec '17

01 Dec '17

#14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14482 Differential Rev(s): | Wiki Page: | ImplementingTreesThatGrow -------------------------------------+------------------------------------- == Context ImplementingTreesThatGrow The intention is to get the first-pass implementation of Trees that Grow into GHC 8.4.1. So far the following commits are on master - https://phabricator.haskell.org/rGHC438dd1cbba13d35f3452b4dcef3f94ce9a216905 - https://phabricator.haskell.org/rGHCe3ec2e7ae94524ebd111963faf34b84d942265b4 - https://phabricator.haskell.org/rGHC47ad6578ea460999b53eb4293c3a3b3017a56d65 Unfortunately we have picked up compile-time performance regressions in compiling GHC itself, with these patches. The perf.haskell.org results are - https://perf.haskell.org/ghc/#revision/438dd1cbba13d35f3452b4dcef3f94ce9a21… - https://perf.haskell.org/ghc/#revision/e3ec2e7ae94524ebd111963faf34b84d9422… - https://perf.haskell.org/ghc/#revision/47ad6578ea460999b53eb4293c3a3b3017a5… Summary: each of the three patches caused GHC validate time to worsen by another 5% or so, cumulatively pushing compile time from 2011 to 2400 seconds. It seems the major culprit is deriving the `Data` instances, probably related to the complex constraint sets required to ensure that all the extension points have `Data` instances too. Some discussion around this is captured in ImplementingTreesThatGrow/Instances == Things tried so far PLAN E (ImplementingTreesThatGrow/Instances#PLANE), in https://github.com/ghc/ghc/tree/wip/ttg5-data-one-file-2017-11-17. This puts all the `Data` derivations for the hsSyn AST into a single file, `hsSyn/HsInstances.hs`. This causes compile-time memory usage to spike up to around 7GB when compiling this file. Gipedia reports a compilation time of 2468 secs for this version, which perhaps indicates that the instance derivation is not the main culprit. The module itself only takes in the order of 45secs to compile, on `home .smart-cactus.org` (http://lpaste.net/7779809210564345856) Splitting the `HsInstances.hs` file in 2, as per https://github.com/ghc/ghc/tree/wip/ttg5-data-2017-11-17 reduces the memory requirement for each, but shows up #14482, where there is a linker failure due to incorrectly processing boot files. == Next Steps I guess the first thing to do is to try to isolate what precisely is causing the slowdown. It may not be instance generation at all. Also, it is probably better to revert the three patches from master, when cutting the 8.4 initial freeze. Open to suggestions ... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 48

[GHC] #14539: untouchable type inside the constraints
by GHC 01 Dec '17

01 Dec '17

#14539: untouchable type inside the constraints -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | 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: -------------------------------------+------------------------------------- The following code is taken and simplified from the test-suite of `accelerate-fourier`: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} module UntouchableType (tests) where import Test.QuickCheck (Testable, Arbitrary, arbitrary, quickCheck, ) newtype Sign a = Sign a deriving (Show) instance Arbitrary (Sign a) where arbitrary = undefined quickCheckWithSign :: (Testable prop) => (Sign Double -> prop) -> IO () quickCheckWithSign = quickCheck data Array sh a = Array type family FullShape sh :: * data SubTransform a = SubTransform (forall sh. (FullShape sh ~ sh) => Array sh a) transform2d :: SubTransform Double -> Bool transform2d = undefined transformChirp2 :: Sign a -> Array sh a transformChirp2 = undefined tests :: IO () tests = quickCheck $ \sign -> transform2d (SubTransform (transformChirp2 (sign::Sign Double))) }}} GHC-8.2.2 says about it: {{{ [1 of 1] Compiling UntouchableType ( UntouchableType.hs, interpreted ) UntouchableType.hs:34:4: error: • Ambiguous type variable ‘p0’ arising from a use of ‘quickCheck’ prevents the constraint ‘(Arbitrary p0)’ from being solved. Probable fix: use a type annotation to specify what ‘p0’ should be. These potential instances exist: instance (Arbitrary a, Arbitrary b) => Arbitrary (Either a b) -- Defined in ‘Test.QuickCheck.Arbitrary’ instance Arbitrary Ordering -- Defined in ‘Test.QuickCheck.Arbitrary’ instance Arbitrary Integer -- Defined in ‘Test.QuickCheck.Arbitrary’ ...plus 20 others ...plus 62 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: quickCheck $ \ sign -> transform2d (SubTransform (transformChirp2 (sign :: Sign Double))) In an equation for ‘tests’: tests = quickCheck $ \ sign -> transform2d (SubTransform (transformChirp2 (sign :: Sign Double))) | 34 | quickCheck $ \sign -> | ^^^^^^^^^^^^^^^^^^^^^... UntouchableType.hs:35:51: error: • Couldn't match expected type ‘Sign Double’ with actual type ‘p0’ ‘p0’ is untouchable inside the constraints: FullShape sh ~ sh bound by a type expected by the context: forall sh. FullShape sh ~ sh => Array sh Double at UntouchableType.hs:35:20-69 • In the first argument of ‘transformChirp2’, namely ‘(sign :: Sign Double)’ In the first argument of ‘SubTransform’, namely ‘(transformChirp2 (sign :: Sign Double))’ In the first argument of ‘transform2d’, namely ‘(SubTransform (transformChirp2 (sign :: Sign Double)))’ • Relevant bindings include sign :: p0 (bound at UntouchableType.hs:34:18) | 35 | transform2d (SubTransform (transformChirp2 (sign::Sign Double))) | ^^^^ Failed, no modules loaded. }}} I have tested GHC versions back to GHC-7.4.2, all of them report essentially the same type error. I do not really understand the type error message, but here are my observations that I find strange: The type annotation `sign :: Sign Double` does not prevent the type error, but replacing `quickCheck` by `quickCheckWithSign` does. Replacing the constraint `FullShape sh ~ sh` by, e.g. `Show sh`, let the error disappear. Generalizing `transform2d` to `SubTransform a` causes another type error although I expected that `SubTransform Double` can be infered from `Sign Double`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14539> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14531: tcIfaceGlobal (local): not found
by GHC 01 Dec '17

01 Dec '17

#14531: tcIfaceGlobal (local): not found --------------------------------------+--------------------------------- Reporter: bigos | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Windows Msys2 | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I have installed Msys2 on Windows. In Msys2 I have installed Emacs, which I start with a custom cmd script with following environment variables set: {{{ SET PATH=C:\msys64\mingw64\bin;C:\msys64\usr\bin;%PATH% set XDG_DATA_DIRS=c:/msys64/mingw64/share set PKG_CONFIG_PATH=c:/msys64/mingw64/lib/pkgconfig set INCLUDE=c:/msys64/mingw64/include }}} The haskell I have is from Full Haskell Platform, https://haskell.org/platform/download/8.2.1/HaskellPlatform-8.2.1-full- x86_64-setup.exe Then I started eshell which I used to invoke this command: {{{ cabal install gi-gtk }}} Which after a while gave me following error. {{{ [91 of 95] Compiling GI.Pango.Objects.Layout ( GI\Pango\Objects\Layout.hs, dist\build\GI\Pango\Objects\Layout.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing Layout which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find Layout in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\iface\TcIface.hs:1696:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory 'C:\Users\Jacek\AppData\Local\Temp\cabal-tmp-8093 \gi-pango-1.0.15' Failed to install gi-gio-2.0.14 Build log ( C:\Users\Jacek\AppData\Roaming\cabal\logs\ghc-8.2.1\gi- gio-2.0.14-GKluzGq73QJBrHtRklhQDd.log ): Preprocessing library for gi-gio-2.0.14.. Building library for gi-gio-2.0.14.. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14531> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14543: Broken links all over the web
by GHC 30 Nov '17

30 Nov '17

#14543: Broken links all over the web -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Example: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /type-families.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

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

30 Nov '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 mpickering): I rebased the branch here - https://github.com/mpickering/ghc/tree/nested- cpr I get 7 test failures running in simpleCore. There is also a core lint error when running a fresh build. I put it up on phab as well for easier viewing. (https://phabricator.haskell.org/D4244) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:79> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14503: Killing a thread will block if there is another process reading from a handle
by GHC 29 Nov '17

29 Nov '17

#14503: Killing a thread will block if there is another process reading from a handle ----------------------------------------+--------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When trying to kill a thread, the program (which uses a thread) hangs if there is another process trying to read from a handle. This bug can be reproduced with using [https://github.com/capitanbatata/sandbox/tree/master/dangling-connections this sample code]. I'll explain the relevant details below. I have the following Haskell code: {{{#!hs someFuncWithChans :: IO () someFuncWithChans = withSocketsDo $ do h <- connectTo "localhost" (PortNumber 9090) hSetBuffering h NoBuffering ch <- newChan putStrLn "Starting the handler reader" readerTid <- forkIO $ handleReader h ch cmdsHandler h ch putStrLn "Killing the handler reader" killThread readerTid putStrLn "Closing the handle" hClose h cmdsHandler :: Handle -> Chan Action -> IO () cmdsHandler h ch = do act <- readChan ch case act of Quit -> putStrLn "Bye bye" Line line -> do hPutStrLn h (reverse line) cmdsHandler h ch handleReader :: Handle -> Chan Action -> IO () handleReader h ch = forever $ do line <- strip <$> hGetLine h case line of "quit" -> writeChan ch Quit _ -> writeChan ch (Line line) data Action = Quit | Line String }}} Is the function `someFuncWithChans` is run along with the following Java program, then the former will block while killing the handler reader (`readerTid`). {{{#!java public static void main(String[] args) throws IOException, InterruptedException { ServerSocket serverSock = new ServerSocket(9090); Socket sock = serverSock.accept(); InputStream inStream = sock.getInputStream(); BufferedReader sockIn = new BufferedReader(new InputStreamReader(inStream)); OutputStream outStream = sock.getOutputStream(); PrintWriter sockOut = new PrintWriter(new OutputStreamWriter(outStream)); while (true) { Thread.sleep(1000); System.out.println("Sending foo"); sockOut.println("foo"); sockOut.flush(); String s = sockIn.readLine(); System.out.println("Got " + s ); Thread.sleep(1000); System.out.println("Sending bar"); sockOut.println("bar"); sockOut.flush(); s = sockIn.readLine(); System.out.println("Got " + s ); Thread.sleep(1000); System.out.println("Sending quit"); sockOut.println("quit"); sockOut.flush(); // This will cause someFuncWithChans to block when killing the // reader thread. s = sockIn.readLine(); System.out.println("Got " + s ); } } }}} If the `sockIn.readLine()` is commented out, then killing the thread will succeed. This problem appears only on my Windows machine (at work), whereas it does not on my personal Linux machine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14503> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14528: LLVM's CallAnalyzer Breaks
by GHC 29 Nov '17

29 Nov '17

#14528: LLVM's CallAnalyzer Breaks -------------------------------------+------------------------------------- Reporter: kavon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (LLVM) | Keywords: inline | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: 11295 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found this issue while working on #11295. It seems that after first running `-mem2reg -inline` on some nofib programs, such as `imaginary/integrate` and `real/lift` (using `llvm-link` to roll the IR files together), running another pass that depends on LLVM's CallAnalyzer will cause `opt` to overflow the stack. For example, here are some pass sequences that break `opt` when optimizing `integrate`: * `-mem2reg -inline -gvn` * `-mem2reg -inline -instcombine` * `-mem2reg -inline -early-cse` This happens in LLVM 5 and tip-of-tree (LLVM 6). It probably is present in LLVM 4 as well. I'm working on putting together a reduced test case to report a bug to LLVM developers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14528> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

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

29 Nov '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 mpickering): Did this patch ever get submitted? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:78> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14511: indexArray# getting poorly deferred
by GHC 29 Nov '17

29 Nov '17

#14511: indexArray# getting poorly deferred -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In both of the following functions I am attempting to execute a read from an `Array# a` and then write the result to a `MutableArray# s a`, and I would like the following evaluation properties: * the `a` value is not forced, i.e. the value stored in the `MutableArray# s a` will remain a thunk if the original value in the `Array# a` was; and * the new `MutableArray#` does not maintain any references to the original `Array#`, so that the original can be GCed. The singleton-unboxed-tuple return type of `indexArray#` appears to be there to allow specifically this use case, but sadly it only succeeds for the first of these functions. The second function ends up storing a thunk in the `MutableArray#` which contains a reference to the `Array#`. Haskell: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module IndexThenWrite where import GHC.Prim indexThenWrite :: Array# a -> MutableArray# s a -> State# s -> State# s indexThenWrite arr marr s = case indexArray# arr 123# of (# a #) -> writeArray# marr 234# a s indexThenWriteF :: (a -> b) -> Array# a -> MutableArray# s b -> State# s -> State# s indexThenWriteF f arr marr s = case indexArray# arr 123# of (# a #) -> writeArray# marr 234# (f a) s }}} Core: {{{#!hs -- RHS size: {terms: 15, types: 18, coercions: 0, joins: 0/0} indexThenWrite indexThenWrite = \ @ a_aq9 @ s_aqa arr_apa marr_apb s1_apc -> case indexArray# arr_apa 123# of { (# ipv_sUH #) -> writeArray# marr_apb 234# ipv_sUH s1_apc } -- RHS size: {terms: 18, types: 22, coercions: 0, joins: 0/0} indexThenWriteF indexThenWriteF = \ @ a_aq0 @ b_aq1 @ s_aq2 f_ape arr_apf marr_apg s1_aph -> writeArray# marr_apg 234# (case indexArray# arr_apf 123# of { (# ipv_sUK #) -> f_ape ipv_sUK }) s1_aph }}} I'd like the second function to generate code similar to the first. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14511> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14454: Unregisterised build is broken
by GHC 28 Nov '17

28 Nov '17

#14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Fails with several errors along the lines of, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20171111 for x86_64-unknown-linux): pprCLbl AsmTempLabel Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/Exception.o' failed make[1]: *** [rts/dist/build/Exception.o] Error 1 make[1]: *** Waiting for unfinished jobs.... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14454> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7