January 2019 - ghc-tickets

[GHC] #16118: SYB link in Data.Data is dead
by GHC 10 Jan '19

10 Jan '19

#16118: SYB link in Data.Data is dead -------------------------------------+------------------------------------- Reporter: ocramz | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: | Version: 8.6.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The link to the SYB blog given in the Data.Data haddocks (http://foswiki.cs.uu.nl/foswiki/bin/view/GenericProgramming/SYB) is dead. Is there a backup copy somewhere? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16165: Move Hadrian (github) wiki information to in-tree docs
by GHC 10 Jan '19

10 Jan '19

#16165: Move Hadrian (github) wiki information to in-tree docs -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: (Hadrian) | 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: -------------------------------------+------------------------------------- https://github.com/snowleopard/hadrian/wiki contains useful information about debugging/testing/profiling Hadrian. We definitely want to move this in the source tree. I'll take care of this in the upcoming weeks (this is not the most urgent Hadrian task, to be honest), unless someone beats me to it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7026: Impredicative implicit parameters
by GHC 10 Jan '19

10 Jan '19

#7026: Impredicative implicit parameters -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: Resolution: | ImpredicativeTypes 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ImpredicativeTypes -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7026#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16143: Some cost centre stacks are not registered via registerCcsList()
by GHC 10 Jan '19

10 Jan '19

#16143: Some cost centre stacks are not registered via registerCcsList() -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.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: -------------------------------------+------------------------------------- In #15508 I observe that some closures have incorrect CCS field. To be able to catch this problem as early as possible I implemented a simple check: {{{ static void checkClosureProfSanity(const StgClosure *p) { StgProfHeader prof_hdr = p->header.prof; CostCentreStack *ccs = prof_hdr.ccs; // For now just make sure the CCS is a registered CCS and not a pointer to // some random heap closure (happened before, see #15508). for (CostCentreStack *ccs_ = CCS_LIST; ccs_; ccs_ = ccs_->prevStack) { if (ccs == ccs_) { return; } } barf("CCS for closure %p is not registered: %p", (void*)p, (void*)ccs); } }}} I call this on all closures before and after a GC. This assumes that all cost centre stacks are registered via `registerCcsList()`, however this currently does not hold. I was able to find two cases: - `base_GHCziIOziHandleziFD_CAFs_cc_ccs` is never registered (there are probably a few CCSs per module like this which are never registered) - None of the dynamically allocated CCSs are registered. My question is: am I misunderstanding how the CCS registry (`CCS_LIST`) is supposed to be used? I thought all CCSs should really be in that list, because the list is used when reporting. Not registering a CCS means not reporting it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16091: arith011 broken with integer-simple
by GHC 09 Jan '19

09 Jan '19

#16091: arith011 broken with integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The `arith011` test fails unexpected when using `integer-simple`. The test output is [[https://gitlab.haskell.org/ghc/ghc/-/jobs/4892/raw|quite long]] but here is the end: {{{ # negate 0 = 0 # testReal toRational 0 = 0 % 1 toRational 1 = 1 % 1 toRational 2 = 2 % 1 toRational 3 = 3 % 1 # testIntegral Stderr ( arith011 ): arith011: divide by zero *** unexpected failure for arith011(normal) }}} This is concerning since it suggests a behavioral difference between `integer-simple` and `integer-gmp`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5793: make nofib awesome
by GHC 09 Jan '19

09 Jan '19

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): #15999 | Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its overall design is OK but it's had no love and care for many > years and has bittrotted such that it isn't useful in a lot of > situations. > > This task is about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > '''Note''' there is a shake build system attached that does a lot of this > (done by Neil Mitchell!). An explanation of it can be found here: > http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- > shake.html > > The design discussion of it is mostly lost as it was done on private > email sorry. > > 2. Fixup the runtimes for benchmarks to be significant. This might be > best done by changing the way we run benchmarks and collect results to > make sure they are meaningful (cf. #15357). > > E.g., Lots of great discussion and links to papers on this thread > > http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. '''Note''' there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- shake.html The design discussion of it is mostly lost as it was done on private email sorry. 2. ~~Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful (cf. #15357)~~ done in #15999. E.g., Lots of great discussion and links to papers on this thread http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html 3. ~~Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second.~~ Done, we determined that 0.1-0.2/1-2/5-10 for fast/norm/slow are the brackets to aim for. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:42> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15999: Stabilise nofib runtime measurements
by GHC 09 Jan '19

09 Jan '19

#15999: Stabilise nofib runtime measurements -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: 8.6.2 benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #5793 #9476 | #15333 #15357 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With Phab:D4989 (cf. #15357) having hit `nofib` master, there are still many benchmarks that are unstable. I identified three causes for unstability in https://ghc.haskell.org/trac/ghc/ticket/5793#comment:38. With system overhead mostly out of the equation, there are still two related tasks left: 1. Identify benchmarks with GC wibbles. Plan: Look at counted instructions while varying heap size with just one generation. A wibbling benchmark should have quite diverse sampled maximum residency (as opposed to a microbenchmark, which should have quite stable instruction count). Then fix these by iterating `main` 'often enough'. Maybe look at total bytes allocated for that, we want this to be monotonically declining as the initial heap size grows. 2. Now, all benchmarks should have stable instruction count. If not, maybe there's another class of benchmarks I didn't identify yet in #5793. Of these benchmarks, there are a few, like `real/eff/CS`, that still have highly unstable runtimes. Fix these 'microbenchmarks' by hiding them behind a flag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15999> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15357: Make nofib suitable for runtime measurements.
by GHC 09 Jan '19

09 Jan '19

#15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: NoFib | Version: 8.4.3 benchmark suite | 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: -------------------------------------+------------------------------------- Currently many benchmarks in a default nofib run have runtimes so low that they become meaningless. This comes with a bunch of issues: * It takes up build/runtime while not actually improving the accuracy of runtime measurements. * It skews results as the jump from 1ms to 2ms registers as a 200% change. * It can hide regression which fall outside of the measured granularity. * Higher number of runs per benchmark spend far too much time on the few slower benchmarks. At the extreme end there are 9 benchmarks with runtimes shorter than the granularity of 1ms. For some benchmarks changing this might be as easy as increasing the number of runs/iterations. For others changing problem sizes is not as easy since they process more complex input data. Below are the runtimes of a recent default nofib run. ||= benchmark =|| Time (ms) || || ansi || 0 || || awards || 0 || || banner || 0 || || calendar || 0 || || expert || 0 || || gen_regexps || 0 || || grep || 0 || || pretty || 0 || || scc || 0 || || cse || 1 || || eliza || 1 || || lift || 1 || || mkhprog || 1 || || prolog || 1 || || sorting || 1 || || veritas || 1 || || knights || 2 || || minimax || 2 || || x2n1 || 2 || || mandel2 || 3 || || parstof || 3 || || fluid || 4 || || pic || 4 || || boyer2 || 5 || || bspt || 5 || || cryptarithm2 || 5 || || fish || 6 || || gg || 6 || || reptile || 6 || || symalg || 6 || || tak || 6 || || VSD || 7 || || rfib || 7 || || queens || 9 || || rewrite || 9 || || sched || 11 || || fem || 12 || || fibheaps || 13 || || parser || 14 || || rsa || 14 || || genfft || 15 || || clausify || ansi || 0 || || awards || 0 || || banner || 0 || || calendar || 0 || || expert || 0 || || gen_regexps || 0 || || grep || 0 || || pretty || 0 || || scc || 0 || || cse || 1 || || eliza || 1 || || lift || 1 || || mkhprog || 1 || || prolog || 1 || || sorting || 1 || || veritas || 1 || || knights || 2 || || minimax || 2 || || x2n1 || 2 || || mandel2 || 3 || || parstof || 3 || || fluid || 4 || || pic || 4 || || boyer2 || 5 || || bspt || 5 || || cryptarithm2 || 5 || || fish || 6 || || gg || 6 || || reptile || 6 || || symalg || 6 || || tak || 6 || || VSD || 7 || || rfib || 7 || || queens || 9 || || rewrite || 9 || || sched || 11 || || fem || 12 || || fibheaps || 13 || || parser || 14 || || rsa || 14 || || genfft || 15 || || clausify || 17 || || gamteb || 17 || || fft || 18 || || boyer || 20 || || gcd || 20 || || sphere || 21 || || fft2 || 23 || || infer || 25 || || maillist || 25 || || mandel || 27 || || nucleic2 || 30 || || primes || 34 || || cichelli || 35 || || ida || 39 || || listcompr || 41 || || listcopy || 43 || || multiplier || 43 || || wang || 43 || || hpg || 45 || || anna || 46 || || reverse-complem || 46 || || integrate || 48 || || primetest || 50 || || paraffins || 54 || || solid || 54 || || puzzle || 55 || || treejoin || 61 || || compress2 || 64 || || compress || 65 || || event || 65 || || bernouilli || 74 || || comp_lab_zift || 78 || || simple || 86 || || wheel-sieve2 || 91 || || life || 100 || || exp3_8 || 102 || || wave4main || 103 || || typecheck || 106 || || atom || 110 || || fulsom || 112 || || CS || 116 || || para || 120 || || kahan || 138 || || transform || 145 || || power || 150 || || cacheprof || 151 || || hidden || 160 || || scs || 168 || || lcss || 175 || || wheel-sieve1 || 199 || || VS || 204 || || pidigits || 216 || || FS || 222 || || last-piece || 230 || || fasta || 263 || || cryptarithm1 || 264 || || CSD || 272 || || digits-of-e1 || 273 || || binary-trees || 342 || || digits-of-e2 || 381 || || circsim || 418 || || S || 451 || || VSM || 497 || || lambda || 617 || || integer || 905 || || n-body || 1043 || || linear || 1070 || || spectral-norm || 1132 || || constraints || 1171 || || exact-reals || 1289 || || mate || 1955 || || fannkuch-redux || 2185 || || k-nucleotide || 2989 || || 17 || || gamteb || 17 || || fft || 18 || || boyer || 20 || || gcd || 20 || || sphere || 21 || || fft2 || 23 || || infer || 25 || || maillist || 25 || || mandel || 27 || || nucleic2 || 30 || || primes || 34 || || cichelli || 35 || || ida || 39 || || listcompr || 41 || || listcopy || 43 || || multiplier || 43 || || wang || 43 || || hpg || 45 || || anna || 46 || || reverse-complem || 46 || || integrate || 48 || || primetest || 50 || || paraffins || 54 || || solid || 54 || || puzzle || 55 || || treejoin || 61 || || compress2 || 64 || || compress || 65 || || event || 65 || || bernouilli || 74 || || comp_lab_zift || 78 || || simple || 86 || || wheel-sieve2 || 91 || || life || 100 || || exp3_8 || 102 || || wave4main || 103 || || typecheck || 106 || || atom || 110 || || fulsom || 112 || || CS || 116 || || para || 120 || || kahan || 138 || || transform || 145 || || power || 150 || || cacheprof || 151 || || hidden || 160 || || scs || 168 || || lcss || 175 || || wheel-sieve1 || 199 || || VS || 204 || || pidigits || 216 || || FS || 222 || || last-piece || 230 || || fasta || 263 || || cryptarithm1 || 264 || || CSD || 272 || || digits-of-e1 || 273 || || binary-trees || 342 || || digits-of-e2 || 381 || || circsim || 418 || || S || 451 || || VSM || 497 || || lambda || 617 || || integer || 905 || || n-body || 1043 || || linear || 1070 || || spectral-norm || 1132 || || constraints || 1171 || || exact-reals || 1289 || || mate || 1955 || || fannkuch-redux || 2185 || || k-nucleotide || 2989 || -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #5793: make nofib awesome
by GHC 09 Jan '19

09 Jan '19

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): #15999 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf <sebastian.graf@…>): In [changeset:"8632268ad8405f0c01aaad3ad16e23c65771ba49/nofib" 8632268/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="8632268ad8405f0c01aaad3ad16e23c65771ba49" Stabilise benchmarks wrt. GC Summary: This is due to #15999, a follow-up on #5793 and #15357 and changes all benchmarks, some of them (i.e. `wheel-sieve1`, `awards`) rather drastically. The general plan is outlined in #15999: Identify GC-sensitive benchmarks by looking at how productivity rates change over different nursery sizes and iterate `main` of these benchmarks often enough for the non-monotony and discontinuities to go away. I was paying attention that the benchmarked logic is actually run $n times more often, rather than just benchmarking IO operations printing the result of CAFs. When I found benchmarks with insignificant runtime (#15357), I made sure that parameters/input files were adjusted so that runtime of the different modes fall within the ranges proposed in https://ghc.haskell.org/trac/ghc/ticket/15357#comment:4 - fast: 0.1-0.2s - norm: 1-2s - slow: 5-10s This is what I did: - Stabilise bernoulli - Stabilise digits-of-e1 - Stabilise digits-of-e2 - Stabilise gen_regexp - Adjust running time of integrate - Adjust running time of kahan - Stabilise paraffins - Stabilise primes - Adjust running time of rfib - Adjust running time of tak - Stabilise wheel-sieve1 - Stabilise wheel-sieve2 - Adjust running time of x2n1 - Adjust running time of ansi - Adjust running time of atom - Make awards benchmark something other than IO - Adjust running time of banner - Stabilise boyer - Adjust running time of boyer2 - Adjust running time of queens - Adjust running time of calendar - Adjust runtime of cichelli - Stabilise circsim - Stabilise clausify - Stabilise constraints with moderate success - Adjust running time of cryptarithm1 - Adjust running time of cryptarythm2 - Adjust running time of cse - Adjust running time of eliza - Adjust running time of exact-reals - Adjust running time of expert - Stabilise fft2 - Stabilise fibheaps - Stabilise fish - Adjust running time for gcd - Stabilise comp_lab_zift - Stabilise event - Stabilise fft - Stabilise genfft - Stabilise ida - Adjust running time for listcompr - Adjust running time for listcopy - Adjust running time of nucleic2 - Attempt to stabilise parstof - Stabilise sched - Stabilise solid - Adjust running time of transform - Adjust running time of typecheck - Stabilise wang - Stabilise wave4main - Adjust running time of integer - Adjust running time of knights - Stabilise lambda - Stabilise lcss - Stabilise life - Stabilise mandel - Stabilise mandel2 - Adjust running time of mate - Stabilise minimax - Adjust running time of multiplier - Adjust running time of para - Stabilise power - Adjust running time of primetest - Stabilise puzzle with mild success - Adjust running time for rewrite - Stabilise simple with mild success - Stabilise sorting - Stabilise sphere - Stabilise treejoin - Stabilise anna - Stabilise bspt - Stabilise cacheprof - Stablise compress - Stablise compress2 - Stabilise fem - Adjust running time of fluid - Stabilise fulsom - Stabilise gamteb - Stabilise gg - Stabilise grep - Adjust running time of hidden - Stabilise hpg - Stabilise infer - Stabilise lift - Stabilise linear - Attempt to stabilise maillist - Stabilise mkhprog - Stabilise parser - Stabilise pic - Stabilise prolog - Attempt to stabilise reptile - Adjust running time of rsa - Adjust running time of scs - Stabilise symalg - Stabilise veritas - Stabilise binary-trees - Adjust running time of fasta - Adjust running time of k-nucleotide - Adjust running time of pidigits - Adjust running time of reverse-complement - Adjust running time of spectral-norm - Adjust running time of fannkuch-redux - Adjust running time for n-body Problematic benchmarks: - `last-piece`: Unclear how to stabilise. Runs for 300ms and I can't make up smaller inputs because I don't understand what it does. - `pretty`: It's just much too small to be relevant at all. Maybe we want to get rid of this one? - `scc`: Same as `pretty`. The input graph for which SCC analysis is done is much too small and I can't find good directed example graphs on the internet. - `secretary`: Apparently this needs `-package random` and consequently hasn't been run for a long time. - `simple`: Same as `last-piece`. Decent runtime (70ms), but it's unstable and I see no way to iterate it ~100 times in fast mode. - `eff`: Every benchmark is problematic here. Not from the point of view of allocations, but because the actual logic is vacuous. IMO, these should be performance tests, not actual benchmarks. Alternatively, write an actual application that makes use of algebraic effects. - `maillist`: Too trivial. It's just String/list manipulation, not representative of any Haskell code we would write today (no use of base library functions which could be fused, uses String instead of Text). It's only 75 loc according to `cloc`, that's not a `real` application. Reviewers: simonpj, simonmar, bgamari, AndreasK, osa1, alpmestan, O26 nofib GHC Trac Issues: #15999 Differential Revision: https://phabricator.haskell.org/D5438 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:41> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14271: ghci hangs with -fexternal-interpreter -prof
by GHC 09 Jan '19

09 Jan '19

#14271: ghci hangs with -fexternal-interpreter -prof ----------------------------------------+------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- {{{ ghci -fexternal-interpreter -prof GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Access violation in generated code when reading 00000001001e0418 }}} * The address remains the same between reruns (and reinstalls) of ghc. * Closing the hanging process leaves the launched ghc active in the background. * The directory I launch ghci from doesn't seem to matter. * I have only tried it on my desktop so far (Win10/Skylake) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13