June 2016 - ghc-tickets

[GHC] #12214: In event of framework failure, test suite still deletes temporary directory
by GHC 21 Jun '16

21 Jun '16

#12214: In event of framework failure, test suite still deletes temporary directory -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thomie Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Steps to reproduce: 1. Purposely induce a framework failure WHILE running the test. For example, assuming #12213 is unfixed just output some UTF-8 characters in your test script. 2. Look and see if the `run` directory is still around. Expected result: It is Actual result: It's not Relatedly, if the test suite did ANY cleaning up, it should say how to rerun the test suite without cleaning up. This is esp. important when debugging framework errors, where the vagaries of the test output could be key to solving the problem. Assigning to thomie since he's been changing this code recently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

20 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 simonmar): I suspect that R1 is not stable enough, but I'm not sure. You could probably find a smaller test case that fails by running the testsuite with stage=1. In any case, this probably isn't a good idea, at least in general, because if a free var is used more than once then we'll get a memory accesses to reference it each time, rather than loading it into a register. Of course if we run out of registers then it might be a good idea... but that's hard to tell at this stage (better to let the register allocator make that decision). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

20 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): So I was trying to learn more about the codegen using this ticket as the motivation and I think I’m missing something. I was looking at modifying `StgCmmBind.thunkCode` where we unconditionally load all the free variables into registers (before generating the code for the body of the thunk). Instead, I thought we could simply populate the environment with expressions containing the right memory accesses (using `addBindC`). My thinking was that: `node` is already a local register (so shouldn’t change), so anything relative to it should be stable and thus safe to use. Unfortunately, this segfaults `ghc-stage2` (i.e., `ghc- stage1` creates something bad). :-/ I tried using `devel1` flavor but that didn't help find anything (i.e., no assertion failures). Trivial programs compiled by `ghc-stage1` seem to work. So it seems that GHC is large enough to trigger some silly bug in my code, but I’m a bit stuck at what that might be. Any ideas what I’m missing? I’m happy to dig further if you have no ideas (or time), but thought I’d ask if there’s something that’s obviously wrong with the idea or code. Thanks! Code: https://github.com/michalt/ghc/tree/t7198/1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7198#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11980: Testsuite: run each test in its own /tmp directory, after copying required files
by GHC 20 Jun '16

20 Jun '16

#11980: Testsuite: run each test in its own /tmp directory, after copying required files -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- == Plan == For each TEST: * create a directory `<testdir>` inside `/tmp` * link/copy all source files that the test needs into `<testdir>` * run the test inside `<testdir>` * delete `<testdir>` == Benefits == * running tests in parallel always works, even when two tests write to the same file (for example .hi/.o files, from sharing a .hs file). This should reduce the number of unsuspected and annoying validate failures. There is no longer any need to specify `-outputdir` explicitly. * there is no longer any need to add entries to the perpetually out-of- date `testsuite/.gitignore`. * there is no longer any need to specify `extra_clean` or `clean_cmd` setup functions for tests. Sometimes you //will// have to specify which extra files a test needs, using the (new) `extra_files` setup function, but it will be immediately clear when to do so (i.e. the test won't run if you don't). By default only files with the name `<testname>*` are copied to `<testdir>`. * it could become possible to run //ways// for a single test in parallel (i.e. `make TEST=<testname> slow` would become faster) * `clean`ing the testsuite won't be necessary (except for a few files in `testsuite/mk` perhaps) Currently the only way to clean the testsuite is via `make CLEANUP=1 CLEAN_ONLY=1`, which requires a call to the testsuite, which requires building mk/ghc-config first. There are 2 problems with this: * you don't expect a call to `make clean` to start building stuff. Even less so in a pristine source distribution. * most of the time it doesn't clean all files, because lots of tests are missing are have incomplete `extra_clean`s. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12210: allocateExec: can't handle large objects
by GHC 20 Jun '16

20 Jun '16

#12210: allocateExec: can't handle large objects -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ghci T11535.hs` fails on Windows with: {{{ GHCi, version 8.0.0.20160421: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( T11535.hs, interpreted ) ghc.exe: internal error: allocateExec: can't handle large objects (GHC version 8.0.0.20160421 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} See also this comment in `rts/sm/Storage.c`: {{{ /* ---------------------------------------------------------------------------- Executable memory Executable memory must be managed separately from non-executable memory. Most OSs these days require you to jump through hoops to dynamically allocate executable memory, due to various security measures. Here we provide a small memory allocator for executable memory. Memory is managed with a page granularity; we allocate linearly in the page, and when the page is emptied (all objects on the page are free) we free the page again, not forgetting to make it non-executable. TODO: The inability to handle objects bigger than BLOCK_SIZE_W means that the linker cannot use allocateExec for loading object code files on Windows. Once allocateExec can handle larger objects, the linker should be modified to use allocateExec instead of VirtualAlloc. ------------------------------------------------------------------------- */ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9646: Strange performance bug
by GHC 20 Jun '16

20 Jun '16

#9646: Strange performance bug -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: -------------------------------------+------------------------------------- I've been chasing a weird performance bug for about a week now. I've reduced the testcase to the following git repo: https://github.com/erikd/ghc-perfbug-test The Readme.md file in that repo contains an explanation of how to reproduce the issue. The benchmark program in the repo uses Criterion to test the performance of one particular function. Running the program in a particular way results into two significanlty different results. The commands are: {{{ make clean bench-integer.html cp -f bench-integer.html bench-integer-slow.html touch New3/GHC/Integer/Natural.hs && make bench-integer.html }}} The results for one function in the file `New3/GHC/Integer/Natural.hs` is 8 times slower in the first test that the second while the other test function always executes at about the speed. I haven't been able to test this with ghc-7.6.3 because the code uses `isTrue#` which isn't available in 7.6.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9646> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #12211: nofib: Undefined reference to `base_GHCziErr_errorWithoutStackTracezuwild_closure'
by GHC 20 Jun '16

20 Jun '16

#12211: nofib: Undefined reference to `base_GHCziErr_errorWithoutStackTracezuwild_closure' ---------------------------------+--------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------- Running nofib on PowerPC 64-bit Linux fails with: {{{ ==nofib== fannkuch-redux: time to link fannkuch-redux follows... Main.o:(.toc+0x0): undefined reference to `base_GHCziErr_errorWithoutStackTracezuwild_closure' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12211> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 19 Jun '16

19 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:43 gidyn]: > Gen_v3 not going in? At least, not for now. In Phab:D2304, SPJ [https://phabricator.haskell.org/D2304#67443 also asked to repeat the same experiment] in comment:39, but with a four-constructor datatype: {{{#!hs data Bigsum = C0 | C1 | C2 | C3 -- Perhaps not the best name in hindsight... }}} As above, here are [https://gist.github.com/RyanGlScott/8341acaaf38b7fbd6e08c2ffc77aa7bd #file-gen_v1-hs Gen_v1.hs], [https://gist.github.com/RyanGlScott/8341acaaf38b7fbd6e08c2ffc77aa7bd #file-gen_v2-hs Gen_v2.hs], and [https://gist.github.com/RyanGlScott/8341acaaf38b7fbd6e08c2ffc77aa7bd #file-gen_v13-hs Gen_v3.hs], and here are their logs: * [https://gist.github.com/RyanGlScott/8341acaaf38b7fbd6e08c2ffc77aa7bd #file-gen_v1-txt Gen_v1.txt] * `{terms: 143, types: 562, coercions: 239}` * `94,739,056 bytes allocated in the heap` * `Total time 0.201s ( 0.191s elapsed)` * [https://gist.github.com/RyanGlScott/8341acaaf38b7fbd6e08c2ffc77aa7bd #file-gen_v2-txt Gen_v2.txt] * `{terms: 148, types: 638, coercions: 174}` * `93,979,880 bytes allocated in the heap` * `Total time 0.196s ( 0.187s elapsed)` * [https://gist.github.com/RyanGlScott/8341acaaf38b7fbd6e08c2ffc77aa7bd #file-gen_v3-txt Gen_v3.txt] * `{terms: 148, types: 638, coercions: 174}` * `94,281,768 bytes allocated in the heap` * `Total time 0.203s ( 0.192s elapsed)` Curiously, in this example, `v3` fares //worse// than `v2`. Again, I'm not sure what's going on here, and with a sample size of two, it's difficult to conclude if the strategy in `v3` is always better than `v2`. I suspect it's asymptotically better, since we go from an O(//n//) number of `L1`s/`R1`s to an O(log //n//) number, but I'd need more evidence to support that claim. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 19 Jun '16

19 Jun '16

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gidyn): Gen_v3 not going in? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:43> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12205: Program develops space leak with -fprof-auto
by GHC 19 Jun '16

19 Jun '16

#12205: Program develops space leak with -fprof-auto -------------------------------------+------------------------------------- Reporter: kristenk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.4.2 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 program seems to use constant memory when compiled with only `-prof`, but it uses increasing amounts of memory when compiled with `-prof` and `-fprof-auto`. I observed the behavior with GHC 8.0.1, 7.10.3, 7.8.4, 7.6.3, and 7.4.2, but not 7.0.4 (with `-auto-all`). {{{#!hs import System.Environment main :: IO () main = do n <- (read . head) `fmap` getArgs case f [0..(n::Int)] 0 of (xs, s) -> print xs >> print s f :: [Int] -> Int -> ([Int], Int) f [] s = ([], s) f (x:xs) s = let (xs', s') = f xs (x + s) in (x + s : xs', s') }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 $ ghc Main.hs -prof [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ /run/current-system/sw/bin/time ./Main 5000000 > /dev/null 2.80user 0.01system 0:02.82elapsed 100%CPU (0avgtext+0avgdata 6028maxresident)k 0inputs+0outputs (0major+661minor)pagefaults 0swaps }}} {{{ $ ghc Main.hs -prof -fprof-auto [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ /run/current-system/sw/bin/time ./Main 5000000 > /dev/null 4.03user 0.35system 0:04.38elapsed 100%CPU (0avgtext+0avgdata 1574348maxresident)k 0inputs+0outputs (0major+392857minor)pagefaults 0swaps }}} [[Image(no-fprof-auto.png)]] [[Image(fprof-auto.png)]] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3