August 2017 - ghc-devs

Crossreferenced GHC 8.0.2
by Robin Palotai 29 Aug '17

29 Aug '17

Hello GHC devs, I ran haskell-indexer [1] on the GHC 8.0.2 tarball, partly because I find myself reading GHC source from time to time while working on the indexer, and partly since it's fun. First, here you can click around [2] and find where beloved functions are called from: http://stuff.codereview.me/#ghc/compiler/hsSyn/HsBinds.hs?corpus&signature (scroll down a bit, imports are not linked yet). Second, the way I indexed was pretty simple. I took the output of `make`, replaced the ghc used with the ghc_kythe_wrapper, and filtered the lines which included '-c', since I noticed that those duplicate previous large compile lines. This only indexes the stage1 compilation AFAIU. Feel free to suggest a better way to tap into the compilations to get everything properly indexed (and possibly only once). Any comments welcome! Robin [1]: https://github.com/google/haskell-indexer [2]: TLDR UI quirks: - Click the :: in top-left to navigate file tree - Ctrl-Click (on linux) to go directly to definition (otherwise click stuff from bottom pane) - Bottom pane often hides content, close it if stuck.

3 7

RE: [commit: ghc] master: Adjust test suite stats (a055f24)
by David Feuer 28 Aug '17

28 Aug '17

These were regressions from your simplifier refactoring. Yes, we should investigate. I'll open a ticket this evening, unless someone else gets to it first. But we surely don't want to keep CI red on every commit until then. David FeuerWell-Typed, LLP -------- Original message --------From: Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> Date: 8/28/17 4:57 PM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: RE: [commit: ghc] master: Adjust test suite stats (a055f24) David, are you sure we want to accept a more than 5% increase in compile time without investigation? What commit caused these increases? Maybe they are readily squashed? Generally we are trying to improve compiler perf not accept it getting worse! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 28 August 2017 19:34 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Adjust test suite stats (a055f24) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa055f240aeda538c656a59e810870e6a2ccc2db | 7%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D&reserved=0 | | >--------------------------------------------------------------- | | commit a055f240aeda538c656a59e810870e6a2ccc2db7 | Author: David Feuer <David.Feuer(a)gmail.com> | Date: Mon Aug 28 14:35:19 2017 -0400 | | Adjust test suite stats | | T1969 and T12150 were failing (stat too high) | | | >--------------------------------------------------------------- | | a055f240aeda538c656a59e810870e6a2ccc2db7 | testsuite/tests/perf/compiler/all.T | 6 ++++-- | 1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1da2883..cf49981 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -72,7 +72,7 @@ test('T1969', | # 2017-03-24 9261052 (x86/Linux, 64-bit machine) | # 2017-04-06 9418680 (x86/Linux, 64-bit machine) | | - (wordsize(64), 16679176, 15)]), | + (wordsize(64), 19199872, 15)]), | # 2014-09-10 10463640, 10 # post-AMP-update (somewhat | stabelish) | # looks like the peak is around ~10M, but we're | # unlikely to GC exactly on the peak. | @@ -87,6 +87,7 @@ test('T1969', | # 2017-02-01 19924328 (amd64/Linux) Join points (#12988) | # 2017-02-14 16393848 Early inline patch | # 2017-03-31 16679176 Fix memory leak in simplifier | + # 2017-08-25 19199872 Refactor the Mighty Simplifier | | compiler_stats_num_field('bytes allocated', | [(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7 | +1111,8 @@ test('T12150', | [ only_ways(['optasm']), | compiler_stats_num_field('bytes allocated', | [(wordsize(64), 70773000, 5) | - # initial: 70773000 | + # initial: 70773000 | + # 2017-08-25: 74358208 Refactor the Mighty Simplifier | ]), | ], | compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D&reserved=0 _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1

RE: [commit: ghc] master: Adjust test suite stats (a055f24)
by Simon Peyton Jones 28 Aug '17

28 Aug '17

David, are you sure we want to accept a more than 5% increase in compile time without investigation? What commit caused these increases? Maybe they are readily squashed? Generally we are trying to improve compiler perf not accept it getting worse! Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 28 August 2017 19:34 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Adjust test suite stats (a055f24) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa055f240aeda538c656a59e810870e6a2ccc2db | 7%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=WH8x1FkDCAmRas%2F5CIxA7PmqDj1zzfqApfyowKlGdfo%3D&reserved=0 | | >--------------------------------------------------------------- | | commit a055f240aeda538c656a59e810870e6a2ccc2db7 | Author: David Feuer <David.Feuer(a)gmail.com> | Date: Mon Aug 28 14:35:19 2017 -0400 | | Adjust test suite stats | | T1969 and T12150 were failing (stat too high) | | | >--------------------------------------------------------------- | | a055f240aeda538c656a59e810870e6a2ccc2db7 | testsuite/tests/perf/compiler/all.T | 6 ++++-- | 1 file changed, 4 insertions(+), 2 deletions(-) | | diff --git a/testsuite/tests/perf/compiler/all.T | b/testsuite/tests/perf/compiler/all.T | index 1da2883..cf49981 100644 | --- a/testsuite/tests/perf/compiler/all.T | +++ b/testsuite/tests/perf/compiler/all.T | @@ -72,7 +72,7 @@ test('T1969', | # 2017-03-24 9261052 (x86/Linux, 64-bit machine) | # 2017-04-06 9418680 (x86/Linux, 64-bit machine) | | - (wordsize(64), 16679176, 15)]), | + (wordsize(64), 19199872, 15)]), | # 2014-09-10 10463640, 10 # post-AMP-update (somewhat | stabelish) | # looks like the peak is around ~10M, but we're | # unlikely to GC exactly on the peak. | @@ -87,6 +87,7 @@ test('T1969', | # 2017-02-01 19924328 (amd64/Linux) Join points (#12988) | # 2017-02-14 16393848 Early inline patch | # 2017-03-31 16679176 Fix memory leak in simplifier | + # 2017-08-25 19199872 Refactor the Mighty Simplifier | | compiler_stats_num_field('bytes allocated', | [(platform('i386-unknown-mingw32'), 301784492, 5), @@ -1110,7 | +1111,8 @@ test('T12150', | [ only_ways(['optasm']), | compiler_stats_num_field('bytes allocated', | [(wordsize(64), 70773000, 5) | - # initial: 70773000 | + # initial: 70773000 | + # 2017-08-25: 74358208 Refactor the Mighty Simplifier | ]), | ], | compile, | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C382263fbefc643e95a6308d4 | ee436098%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636395420551278722& | sdata=j5wIO8m%2FgR3czmSfjpJlzV4HcMbwrI3nU2C98OmMkV0%3D&reserved=0

1 0

RE: Alex install failure
by Simon Peyton Jones 28 Aug '17

28 Aug '17

| note that you mistyped "lockd" (aka "lock daemon") as "locd" Oh, sorry about mistyping simonpj@cam-05-unx:~/tmp$ ps -Af | grep lockd root 140 2 0 2016 ? 00:00:00 [kblockd] simonpj 7882 1184 0 13:22 pts/7 00:00:00 grep lockd | also, the output of "rpcinfo -p" would be interesting to know simonpj@cam-05-unx:~/tmp$ rpcinfo -p Command 'rpcinfo' is available in '/usr/sbin/rpcinfo' The command could not be located because '/usr/sbin' is not included in the PATH environment variable. This is most likely caused by the lack of administrative privileges associated with your user account. rpcinfo: command not found | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 28 August 2017 12:51 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: Alex install failure | | Simon, | | note that you mistyped "lockd" (aka "lock daemon") as "locd" | | also, the output of "rpcinfo -p" would be interesting to know | | On Mon, Aug 28, 2017 at 1:47 PM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > | Hmm, alright then. What do the following say, | > | | > | * ps -Af | grep lockd | > | * ps -Af | grep portmap | > | * ps -Af | grep rpcbind | > | * mount | grep nfs | > | | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep locd | > simonpj 20138 1184 0 12:46 pts/7 00:00:00 grep locd | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep portmap | > simonpj 22601 1184 0 12:46 pts/7 00:00:00 grep portmap | > | > simonpj@cam-05-unx:~/tmp$ ps -Af | grep rpcbind | > root 1472 1 0 2016 ? 00:00:13 rpcbind -w | > simonpj 26634 1184 0 12:46 pts/7 00:00:00 grep rpcbind | > | > simonpj@cam-05-unx:~/tmp$ mount | grep nfs camresunxa02:/home on /home | > type nfs (rw,intr,vers=4,addr=10.190.50.19,clientaddr=10.190.108.81) | > | > | -----Original Message----- | > | From: Ben Gamari [mailto:ben@well-typed.com] | > | Sent: 25 August 2017 17:46 | > | To: Simon Peyton Jones <simonpj(a)microsoft.com> | > | Cc: ghc-devs <ghc-devs(a)haskell.org> | > | Subject: RE: Alex install failure | > | | > | Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org> writes: | > | | > | > | I have implemented this in wip/ghc-pkg-locking. Do you think | > | you > | could give this branch a try? If it still fails then we'll | > | have to > | try to debug things in-situ. | > | > | > | > Alas, no go. | > | > | > | Hmm, alright then. What do the following say, | > | | > | * ps -Af | grep lockd | > | * ps -Af | grep portmap | > | * ps -Af | grep rpcbind | > | * mount | grep nfs | > | | > | Cheers, | > | | > | - Ben | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csi | > monpj%40microsoft.com%7C33b163bdb97f4f59d80f08d4ee0b07ea%7C72f988bf86f | > 141af91ab2d7cd011db47%7C1%7C0%7C636395178517098924&sdata=EOVdQbvvTDGP9 | > 2o8AHcVEcapHMicnVptxMCpwRPrsvE%3D&reserved=0

3 5

Alex install failure
by Simon Peyton Jones 28 Aug '17

28 Aug '17

Friends I'm trying to update my installation of alex, on Unix (Ubuntu). But I get the dump below It's complaining about a lock file being an invalid argument (see highlight below). If I manually remove the file I get past that, it successfully installs tf-random, but the same thing happens on the next package. So I can install packages one at a time, but that's silly. Any ideas? Simon cabal install alex Resolving dependencies... Configuring tf-random-0.5... Building tf-random-0.5... Failed to install tf-random-0.5 Build log ( /home/simonpj/.cabal/logs/tf-random-0.5.log ): cabal: Entering directory '/tcabal mp/cabal-tmp-26141/tf-random-0.5' Configuring tf-random-0.5... Building tf-random-0.5... Preprocessing library tf-random-0.5... [1 of 4] Compiling System.Random.TF.Gen ( src/System/Random/TF/Gen.hs, dist/build/System/Random/TF/Gen.o ) [2 of 4] Compiling System.Random.TF.Init ( src/System/Random/TF/Init.hs, dist/build/System/Random/TF/Init.o ) src/System/Random/TF/Init.hs:94:5: warning: [-Wdeprecations] In the use of 'bitSize' (imported from Data.Bits): Deprecated: "Use 'bitSizeMaybe' or 'finiteBitSize' instead" | 94 | | bitSize n > 64 = error "mkTFGen: case where size of Int > 64 not implemented" | ^^^^^^^ [3 of 4] Compiling System.Random.TF ( src/System/Random/TF.hs, dist/build/System/Random/TF.o ) [4 of 4] Compiling System.Random.TF.Instances ( src/System/Random/TF/Instances.hs, dist/build/System/Random/TF/Instances.o ) Creating package registration file: /tmp/pkgConf-tf-random-05965166491189641421.5 Installing library in /home/simonpj/.cabal/lib/x86_64-linux-ghc-8.2.1/tf-random-0.5-ABDhxe3mXYlHUEE5hzgewx Registering tf-random-0.5... cabal: '/usr/local/bin/ghc-pkg' exited with an error: ghc-pkg: Couldn't open database /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d for modification: {handle: /home/simonpj/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache.lock}: hLock: invalid argument (Bad file descriptor) cabal: Leaving directory '/tmp/cabal-tmp-26141/tf-random-0.5' cabal: Error: some packages failed to install: QuickCheck-2.10.0.1 depends on tf-random-0.5 which failed to install. alex-3.2.1 depends on tf-random-0.5 which failed to install. tf-random-0.5 failed during the final install step. The exception was: ExitFailure 1 simonpj@cam-05-unx:~/code/HEAD$

5 11

Re: New primitive types?
by David Feuer 27 Aug '17

27 Aug '17

Atomic operations, or the lack thereof, don't seem terribly relevant to immutable Haskell constructor fields. David FeuerWell-Typed, LLP -------- Original message --------From: Carter Schonwald <carter.schonwald(a)gmail.com> Date: 8/26/17 10:56 PM (GMT-05:00) To: Florian Weimer <fw(a)deneb.enyo.de>, Michal Terepeta <michal.terepeta(a)gmail.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: Re: New primitive types? Which architectures are which? I assume you mean the dec alpha allowed atomic operations on bytes... but your phrasing is a teeny bit unclear On Sat, Aug 19, 2017 at 4:34 AM Florian Weimer <fw(a)deneb.enyo.de> wrote: > * Michal Terepeta: > > > On Tue, Aug 1, 2017 at 8:08 PM Carter Schonwald < > carter.schonwald(a)gmail.com> > > wrote: > >> One issue with packed fields is that on many architectures you can't > > quite do subword reads or > >> writes. So it might not always be a win. > > > > Could you give any examples? > > Historic DEC Alpha, now long obsolete. > > It is very hard to create compliant and performant implementations of > Java 5, C 11 or C++ 11 on such architectures. All these languages > (and their subsequent revisions) require that naturally aligned > objects can be accessed independently. For example, you can't use a > simple read-modify-write cycle to implement a single-byte store using > word operations. > > That's why such architectures really do not have a future (or even a > present), except maybe in niche markets such as GPGPU (but even there, > things are heading towards the de-facto standard memory model). >

1 0

Tying knots with strict constructors
by David Feuer 27 Aug '17

27 Aug '17

Once in a while, one desires to tie a recursive knot and is stymied by a strict data constructor. I recently encountered this problem trying to improve the implementation of `never` in the `streaming` package. The Stream type is defined thus: data Stream f m r = Step !(f (Stream f m r)) | Effect (m (Stream f m r)) | Return r It would be nice to be able to write never :: Applicative f => Stream f m r never = fix (Step . pure) Unfortunately, if `pure` is strict (e.g., Identity), this won't work. The Step wrapper attempts to force `pure never` and then apply the Step worker. This will never work. The streaming package works around the problem by representing the `never` stream in a different way, at the potential cost of some efficiency. In other contexts, there may be no (safe) workaround at all. This is terribly frustrating, because it seems almost possible to express what I want in Core, and even possible to express it in Haskell with a really awful unsafeCoerce. The nasty version looks like this: data StreamL f m r = StepL (f (StreamL f m r)) | EffectL (m (StreamL f m r)) | ReturnL r never :: forall f m r. Applicative f => Stream f m r never = case loop of StepL x -> x `pseq` unsafeCoerce loop where loop :: StreamL f m r loop = StepL (pure loop) in loop {-# NOINLINE loop #-} {-# NOINLINE never #-} That is, I make a copy of the Stream type, but with a lazy version of the Step constructor, I tie my knot, I make very sure that the strict field is evaluated, and then I unsafeCoerce the whole thing in a thoroughly unsupported fashion to get back to the right type. Ideally, It would be nice to get GHC to manufacture, and expose to users, bidirectional patterns that offer more access to the raw representation of a type. Basically, I want to get a bidirectional pattern for Step that: 1. Is lazy when used as a constructor (applying the "worker" constructor directly) 2. Is viewed as lazy on matching, so the strictness analysis comes out right. Using such a feature will presumably always be dangerous (unless someone does a ton of work to find an efficient way to make it safe), but I'd rather have a reasonable dangerous way to do it than an unreasonable dangerous way, if that can be accomplished. Unfortunately, I haven't been able to think of a reasonable design for such a language feature. Does anyone else have any ideas? Or some other thought about how such things might be done? David

1 0

Where to raise an issue for the stm library
by Harendra Kumar 26 Aug '17

26 Aug '17

Can someone tell me where to raise an issue for the stm library? The hackage link sends me here http://git.haskell.org/packages/stm.git. But this page provides no clue on raising issues. I wondered if GHC trac itself is used for this library. I saw some other libraries in the drop down list but not this one in the GHC trac ticket creation page. It is frustrating that figuring out how to raise an issue is not easy for such an important library. -harendra

3 5

Discussion: Static Safety via Distinct Interfaces for HsSyn ASTs
by Shayan Najd 25 Aug '17

25 Aug '17

In this thread, I am going to raise a topic for discussion. Please share your opinions and related experiences. Evaluation of type families within HsSyn ASTs, such as `PostTc`, with a fixed phase index, such as `GhcPs`, gives us distinct ASTs at the *compile-time*. However, when programming with these ASTs, we use patterns, such as `HsMultiIf :: PostTc p Type -> [LGRHS p (LHsExpr p)] -> HsExpr p` that are shared among phases. We can (1) introduce a layer of abstraction providing a set of type and pattern synonyms specific to each phase, such as `PsMultiIf :: [LPsGRHS LPsExpr] -> PsExpr`; and (2) updating code working on ASTs of specific phase to use the interface specific to the phase, such as by changing prefixes from `Hs` to `Ps` and by removing unused variables and placeholders; and (3) leaving untouched code working uniformly on ASTs of different phases (i.e., the generic functions in Trees that Grow terminology), such as the existing functions whose types are polymorphic on phase index. Some comments: - It can be done gradually and smoothly: we add three separate files in HsSyn (per each phase) containing the phase-specific interfaces, and gradually import them and do the changes per module. - Using the interfaces is optional: code using the current method (e.g., using `HsMultiIf`) should work just fine. - It introduces a layer of indirection and three more files to maintain. - It makes code working on HsSyn ASTs, such as the renamer, appear cleaner as placeholders and similar machinery are abstracted away by the interfaces (e.g., no need to import bits and pieces of `HsExtension`) - In theory, there should be zero impact on GHC's runtime performance. I am myself undecided about its benefit-cost ratio, but willing to at least implement the phase-specific interfaces. For me, abstracting away all the `PostRn` stuff, `Out` prefixed constructors, and dummy placeholders from the front-end code is the most valuable. Yours, Shayan

2 3

Stg-lint and bootstrapping (fails?)
by Gabor Greif 24 Aug '17

24 Aug '17

Hi all, I tried an stg-lint build thus: $ make V=1 GhcStage2HcOpts="-O1 -g -dstg-lint" ... and failed: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc-prim-0.5.1.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./System/Mem/Weak.hs -o libraries/base/dist-install/build/System/Mem/Weak.o -dyno libraries/base/dist-install/build/System/Mem/Weak.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc-prim-0.5.1.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./Control/Monad/IO/Class.hs -o libraries/base/dist-install/build/Control/Monad/IO/Class.o -dyno libraries/base/dist-install/build/Control/Monad/IO/Class.dyn_o "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O1 -g -dstg-lint -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/utils/Exception.hs -o compiler/stage2/build/Exception.o -dyno compiler/stage2/build/Exception.dyn_o /home/ggreif/%NoBackup%/ghc-head/libraries/base/dist-install/build/GHC/IO/Exception.hi Declaration for $fExceptionIOException4 Unfolding of $fExceptionIOException4: Failed to load interface for ?GHC.Fingerprint? There are files missing in the ?base-4.10.0.0? package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20170815 for x86_64-unknown-linux): kindPrimRep * -> * typePrimRep (m_as6 :: * -> *) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:344:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:305:18 in ghc:RepType typePrimRep, called at compiler/stgSyn/StgLint.hs:437:17 in ghc:StgLint Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <<ghc: 144952288 bytes, 38 GCs, 4093040/9445544 avg/max bytes residency (4 samples), 61M in use, 0.000 INIT (0.000 elapsed), 0.355 MUT (0.386 elapsed), 0.216 GC (0.216 elapsed) :ghc>> make[1]: *** [compiler/stage2/build/Exception.o] Error 1 make: *** [all] Error 2 What is the status of stg-lint? Is the above expected to happen? This is stock `master` branch as of today. Cheers, Gabor

3 10