June 2016 - ghc-tickets

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 23 Jun '16

23 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"bb7402187819a489d933643f694d819b63ae25c2/ghc" bb74021/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb7402187819a489d933643f694d819b63ae25c2" Remove Ord TyCon After 35d1564cea2e: Provide Uniquable version of SCC we can remove this. We want to remove it because when used it can introduce unnecessary nondeterminism. GHC Trac: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:213> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 23 Jun '16

23 Jun '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"35d1564cea2e611a4fecf24f09eff83f8a55af1c/ghc" 35d1564c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="35d1564cea2e611a4fecf24f09eff83f8a55af1c" Provide Uniquable version of SCC We want to remove the `Ord Unique` instance because there's no way to implement it in deterministic way and it's too easy to use by accident. We sometimes compute SCC for datatypes whose Ord instance is implemented in terms of Unique. The Ord constraint on SCC is just an artifact of some internal data structures. We can have an alternative implementation with a data structure that uses Uniquable instead. This does exactly that and I'm pleased that I didn't have to introduce any duplication to do that. Test Plan: ./validate I looked at performance tests and it's a tiny bit better. Reviewers: bgamari, simonmar, ezyang, austin, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2359 GHC Trac Issues: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:212> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11948: GHC forgets constraints
by GHC 23 Jun '16

23 Jun '16

#11948: GHC forgets constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- Possibly related: #10338 The following program should compile, but fails with the error: {{{ Could not deduce (Bar (F zq) zq) arising from a use of ‘bar’ from the context (Bar (Foo (F zq)) (Foo zq)) bound by the type signature for bug :: Bar (Foo (F zq)) (Foo zq) => Foo (F zq) -> Foo zq }}} This is definitely incorrect: I am providing a `Bar` constraint in the context of `bug`, but GHC is asking for constraints so that it can resolve to the instance declared in Bar.hs. A few workarounds I've found so far, which may or may not help find the bug: 1. Adding `-XTypeFamilies` to Main.hs makes the program compile. 2. ''Removing'' the type signature from `x` in `bug` makes the program compile. 3. Defining `bug` without a `let` as `bug sk = bar sk :: Foo zq` or `bug sk = bar sk` makes the program compile. Main.hs: {{{ {-# LANGUAGE FlexibleContexts, ScopedTypeVariables #-} import Bar bug :: forall zq . (Bar (Foo (F zq)) (Foo zq)) => Foo (F zq) -> Foo zq bug sk = let x = bar sk :: Foo zq in x }}} Bar.hs {{{ {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Bar where type family F b newtype Foo r = Foo r type instance F (Foo r) = Foo (F r) class Bar a b where bar :: a -> b instance (Bar a b) => Bar (Foo a) (Foo b) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11948> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12163: Incorrect error message when deriving Functor
by GHC 23 Jun '16

23 Jun '16

#12163: Incorrect error message when deriving Functor -------------------------------------+------------------------------------- Reporter: | Owner: benjamin.hodgson | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect (amd64) | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE GADTs #-} data T a b where Mk :: Int -> b -> T Int b deriving (Functor) }}} GHC says: {{{ Can't make a derived instance of ‘Functor (T a)’: Constructor ‘Mk’ has existentials or constraints in its type Possible fix: use a standalone deriving declaration instead In the data declaration for ‘T’ }}} This is not true - Mk does not existentially quantify anything, nor does it have a constraint in its type. The suggested fix of using a standalone deriving declaration works though. Tested on 7.10.3 running in OSX Mavericks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12163> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12226: C-c does not force kill hung GHC processes
by GHC 23 Jun '16

23 Jun '16

#12226: C-c does not force kill hung GHC processes -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | 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: -------------------------------------+------------------------------------- By default the test timeout is 300sec. One common thing to have occur is you get GHC in an infinite loop, and now a test won't terminate. So you do the obvious thing and C-c the test script. BUT LITTLE DO YOU KNOW, the GHC process is still hanging around. So, Python should probably force kill its subprocesses as its quitting, rather than hope that the SIGHUP will reap them. Timeouts DO kill properly, which is nice. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12226> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12225: Warn if test setting has no effect (e.g. compile_timeout_multiplier on run_command)
by GHC 23 Jun '16

23 Jun '16

#12225: Warn if test setting has no effect (e.g. compile_timeout_multiplier on run_command) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | 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 recently wrote this line in an `all.T`. Can you figure out how it's wrong? {{{ test('tc266', [extra_clean(['Tc266.hi-boot', 'Tc266.o-boot', 'Tc266a.hi', 'Tc266a.o', 'Tc266.hi', 'Tc266.o']), compile_timeout_multiplier(0.01)] , run_command, ['$MAKE -s --no-print-directory tc266']) }}} That's right, it should be `run_timeout_multiplier`, not compile timeout multiplier, which is literally a no-op for this test. There should be a warning if this happens. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7198: New codegen more than doubles compile time of T3294
by GHC 22 Jun '16

22 Jun '16

#7198: New codegen more than doubles compile time of T3294 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): Right, that makes sense - I think I made a wrong assumption that always put the value of `node` (`R1`) register also into a local register (that's what was happening in all my experiments). But that's probably not the case in general (which would invalidate the stored memory loads). Thanks for explanations! As for sinking everything later, as I far as I understand, this ticket is about trying to avoid generating so much Cmm even if it would get sinked later on (because it hurts compile time and sinking pass is not run actually on `-O0`). In any way, I agreed that this might not be the best idea if the free variables are reused multiple times. I'll keep poking around and ping this issue once I have a better idea :-) (or someone else comes up with one) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12221: GHC's signal handlers break C-c C-c force terminate
by GHC 22 Jun '16

22 Jun '16

#12221: GHC's signal handlers break C-c C-c force terminate -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang 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: -------------------------------------+------------------------------------- GHC RTS has a policy that if it can't neatly shut off after the first C-c, it will forcibly terminate after the second one. This works all very well, until we reprogram the signal handler: {{{ import Panic main = do installSignalHandlers let f x | x == 0 = 0 :: Int | otherwise = f (x + 1) print (f (1 :: Int)) }}} Compile this with {{{ ezyang@sabre:~$ ghc-8.0 --make M.hs -O -package ghc ezyang@sabre:~$ ./M ^C^C^C^C^C^C^C^C^Z [1]+ Stopped ./M ezyang@sabre:~$ kill -9 %1 [1]+ Killed ./M }}} So yeah, that's a pain. What this means is that if GHC itself infinite loops, you can't ^C it. Maybe #10686 is exactly this, but my diagnosis doesn't seem to be consistent with their workaround in Leksah. In particular, this program still does not accept C-C: {{{ import Panic import System.Posix.Signals (emptySignalSet, sigINT, addSignal, unblockSignals) main = do installSignalHandlers unblockSignals $ addSignal sigINT emptySignalSet let f x | x == 0 = 0 :: Int | otherwise = f (x + 1) print (f (1 :: Int)) }}} #4162 is people asking GHC to NOT install signal handlers unless we are running GHCi; this would also solve the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10686: Process stops responding to sigINT
by GHC 22 Jun '16

22 Jun '16

#10686: Process stops responding to sigINT -------------------------------------+------------------------------------- Reporter: hamish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Every now and then the leksah-server process has required a kill -9 it to get rid of it. Now Leksah is using the threaded RTS it seems to be happening in Leksah too. It is worse in Leksah because child processes inherit the behaviour and do not terminate when sent Leksah sends them sigINT (which Leksah does very frequently). Once the problem arrises it continues until the Leksah is restarted. Both leksah-server and Leksah start child processes using the process package. I think process package and the GHC GC both call blockUserSignals and it only has one place to store savedSignals. My guess is that two calls go into blockUserSignals from different threads before unblockUserSignals is called on either. The result is that when unblockUserSignals is called it does nothing (because savedSignals was overwritten). Perhaps savedSignals could use some kind of thread local storage? Also docs seem to indicate sigprocmask should not be used at all in multithreaded processes. Perhaps the GHC RTS should use pthread_sigprocmask instead? If the calling process delegates Ctrl+C the problem might be largely hidden. The sigINT signal is enabled again in the child fork and the parent will get an exception if the child is terminated with a sigINT. However I believe the parent is still left in a state where it will no longer respond to sigINT if the child process terminates normally (assuming two calls in a row were made to blockUserSignals at some point). The work around for now in Leksah is to reenable sigINT before each createProcess call. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10686> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12191: 7% allocation regression in Haddock performance tests
by GHC 22 Jun '16

22 Jun '16

#12191: 7% allocation regression in Haddock performance tests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One of the commits below is responsible for a rather significant [[https://perf.haskell.org/ghc/#revision/d55a9b4fd5a3ce24b13311962bca66155b17…]] in the `haddock.Cabal` and `haddock.compiler` testcases, {{{ d55a9b4fd5a3ce24b13311962bca66155b17a558 0497ee504cc9ac5d6babee9b98bf779b3fc50b98 586d55815401c54f4687d053fb033e53865e0bf1 7de776cfe7825fca6a71fe6b3854c3c86bf9ca12 5cee88d766723929f789ffcd2ef24d8b5ef62a16 1dcb32ddba605bced2e0e0ce3f52b58e8ff33f5b 921ebc9f0854d033cbafd43d3b2c5ba679c27b3c e064f501d76c208ddab3c3be551ffe5167d7974f 8104f7c674d7ef2db0c25312f48763202dcef57f 599d912f0b85583e389661d85ed2f198e2621bb0 15fc52819c440f9e9b91ce92fcfda3c264cbe1c1 1f661281a23b6eab83a1144c43e464c0e2d2195a 35c9de7ca053eda472cb446c53bcd2007bfd8394 7afb7adf45216701e4f645676ecc0668f64b424d c28dde37f3f274a2a1207dd4e175ea79769f5ead 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72 }}} It would be nice to identify which of these is the culprit. The fix in `d55a9b4fd5a3ce24b13311962bca66155b17a558` will need to be applied on top of each of these to allow things to build. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14