- ghc-devs - Haskell.org

make install fails on master on macOS Sierra
by Mitsutoshi Aoe 28 Apr '17

28 Apr '17

Hi ghc devs, I'm trying to build recent master (579bb766) on macOS Sierra but make install fails as follows: "/usr/local/ghc/ghc-HEAD/lib/ghc-8.3.20170426/bin/ghc-pkg" --force --global-package-db "/usr/local/ghc/ghc-HEAD/lib/ghc-8.3.20170426/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. : Warning: Unrecognized field exposed-modules on line 708 : Warning: Unrecognized field key on line 703 : Warning: Unrecognized field id on line 702 : Warning: Unrecognized field version on line 701 : Warning: Unrecognized field name on line 700 : invalid package identifier: : missing id field make[1]: *** [install_packages] Error 1 make: *** [install] Error 2 The package.conf.install in question is available here: https://gist.github.com/maoe/2cff85004ef8765937023425c53f2cc7. And my build.mk is here: https://gist.github.com/maoe/caee7b2dfd921def4e95580c202cd664 I can't reproduce this error on Linux. Does anyone know how to fix it? Regards, Mitsutoshi

2 4

Pushing to nofib
by Simon Peyton Jones 28 Apr '17

28 Apr '17

How can I push to the nofib repository? I get this: simonpj@cam-05-unx:~/code/HEAD-4/nofib$ git push fatal: remote error: access denied or repository not exported: /nofib.git Thanks Simon

2 3

NCG lowering of sqrt
by Kavon Farvardin 28 Apr '17

28 Apr '17

Given a Cmm expression such as (_c8Gq::F64) = call MO_F64_Sqrt(_s8oX::F64); // CmmUnsafeForeignCall the native code generator produces an actual call to the sqrt C function, which has the side-effect of causing all floating-point registers to be dumped as they are caller-saved. In the nbody benchmark, this is particularly bad for a rather hot piece of code (see below). Ideally the NCG would recognize this foreign call and instead use the `sqrtsd` SSE instruction when targeting x86-64. Does anyone know if the NCG can produce this instruction? I think it would be beneficial, as the below would turn into one or two instructions. Other math functions such as sin/cos require x87 FPU instructions, which as far as I know we're not using. ;;;;;;;;;;; ; NCG generates this in parts of the nbody benchmark ; to compute the sqrt ; subq $8,%rsp movsd %xmm9,176(%rsp) ; all floating-point registers movsd %xmm1,184(%rsp) ; are caller-saved in SysV ABI movsd %xmm2,192(%rsp) movsd %xmm3,200(%rsp) movq %rdi,208(%rsp) movq %rcx,216(%rsp) movq %rsi,224(%rsp) movsd %xmm4,232(%rsp) movsd %xmm5,240(%rsp) movsd %xmm6,248(%rsp) movsd %xmm7,256(%rsp) movsd %xmm8,264(%rsp) movsd %xmm11,272(%rsp) call _sqrt ;; the loads ;; below are interleaved ;; with computations addq $8,%rsp movsd 264(%rsp),%xmm1 movsd 240(%rsp),%xmm2 movsd 224(%rsp),%xmm2 movsd 232(%rsp),%xmm4 movq 200(%rsp),%rax movsd 248(%rsp),%xmm4 movsd 256(%rsp),%xmm4 movq 216(%rsp),%rcx movsd 192(%rsp),%xmm2 ~kavon

3 2

Constraint solver iterations
by amindfv＠gmail.com 27 Apr '17

27 Apr '17

To build the 'vivid' package (on Hackage) with recent versions of GHC (I believe the problem is with 8.0+, didn't see it before then), I need to compile with -fconstraint-solver-iterations=0. (0 meaning unbounded) However, I noticed today that the GHC docs say "Typically one iteration suffices; so please yell if you find you need to set it higher than the default." The code (in Vivid.SynthDef.FromUA) uses a large amount of type family recursion. Is this not a case where I should be yelling? If I should be, I can provide a smaller repro case. If this is expected, are there techniques for rewriting the code in a way that'll fit under the default number of iterations? I've tried rewriting, making the number of iterations logarithmic instead of linear (e.g. by appending lists instead of cons-ing), but still hit the problem (even with an increased but bounded number of iteration steps). Thanks! Tom

2 1

Re: Re: Re-compiling wired-in packages
by Shao Cheng 25 Apr '17

25 Apr '17

Hi, > I did just that recently, see > https://github.com/nomeata/veggies > for how I did it, in particular boot.sh. Thank you for your work! I looked at boot.sh, and tried the "ghc Setup.hs && ./Cabal" approach. It works for ghc-prim & integer-simple, but not base. Since porting gmp to my target platform is hard, I chose integer-simple, and "./Cabal build" produces the following error message for base: Preprocessing library for base-4.10.0.0.. Building library for base-4.10.0.0.. [ 1 of 238] Compiling GHC.IO[boot] ( GHC/IO.hs-boot, dist/build/GHC/IO.o-boot ) [ 2 of 238] Compiling GHC.Stack.Types ( GHC/Stack/Types.hs, dist/build/GHC/Stack/Types.o ) GHC/Stack/Types.hs:57:1: error: Bad interface file: /home/shaocheng/hana/lib/x86_64-linux-ghc-8.3.20170423/integer-simple-0.1.1.1-FieYyHVQ4yaKr3TU2vSN3a/GHC/Integer.hi Something is amiss; requested module integer-simple-0.1.1.1:GHC.Integer differs from name found in the interface file integer-simple:GHC.Integer (if these names look the same, try again with -dppr-debug) | 57 | import GHC.Integer () | ^^^^^^^^^^^^^^^^^^^^^ The compilation for integer-simple didn't produce error, and it is properly registered by ghc-pkg, so I've no idea why there's a bad interface file. Do you have any ideas on possible causes? Thanks a lot. Greetings, Shao Cheng

2 1

debug output
by Simon Peyton Jones 24 Apr '17

24 Apr '17

mk/flavours/validate.mk has GhcStage2HcOpts = -O -dcore-lint GhcLibHcOpts = -O -dcore-lint How can I override these in my validate.mk? E.g. GhcLibHcOpts += -ddebug-output does not work. Thanks. One should really be able to override anything. Simon

3 4

Re-compiling wired-in packages
by Shao Cheng 24 Apr '17

24 Apr '17

Dear friends, I'm trying to implement a new codegen for ghc, starting by using the ghc api to compile modules to STG/Cmm. In order to support importing Prelude, I also need the STG/Cmm representations of wired-in packages like base, ghc-prim, etc, and I guess that means I need to re-compile them. I can roughly think of two approaches: * Load the `ModIface` of wired-in packages, which are tidied Core modules, and convert to STG/Cmm * Get the library sources from ghc repo and launch a regular compilation. I haven't succeeded in either approach. For the first one, I haven't found a way to convert `ModIface` of external package to regular compilation targets; for the second one, regular "cabal installs" won't do the trick, seems compiling wired-in packages require quite some magic. What is the preferred way of re-compiling wired-in packages and retrieving their STG/Cmm representations? Thank a lot. Cheers, Shao Cheng

2 1

Harbormaster out to sea?
by Richard Eisenberg 24 Apr '17

24 Apr '17

I've posted a few diffs today, but Harbormaster seems stalled in checking them: - https://phabricator.haskell.org/D3424 - https://phabricator.haskell.org/D3487 - https://phabricator.haskell.org/D3490 Do you have any insight into this? Thanks! Richard

2 1

GHC Build System & Cabal
by Moritz Angermann 21 Apr '17

21 Apr '17

Dear friends, I’m currently exploring the possibility to build two versions of base similar to how we build various ways of the rts. The reasons for doing this won’t add much to the discussion. Reading https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Cabal I find the following: > For the GHC build system we need to extract that metadata and use > it to build the package. which leaves me wondering why that is? Initially I expected we’d just shell out and let cabal do the configuration and building of .cabal’ised packages. But it seems to be the case that we sidestep cabal for building ghc. Can someone shed some light on the reasoning behind this? Cheers, Moritz

2 1

Re: [Diffusion] [Raised Concern] rGHC751996e90a96: Kill off complications in CoreFVs
by Joachim Breitner 18 Apr '17

18 Apr '17

[CC’ing ghc-dev in case others are also curious about how to navigate Gipeda.] Hi, Am Donnerstag, den 13.04.2017, 08:40 +0000 schrieb Simon Peyton Jones: > Thanks for noticing this! I will investigate. > > But where do you see this? > · at perf.haskell.org I see “GHC” and “Gipeda”. It’s not > obvious which I want. You want the GHC Dashboard, as you guessed correctly. > · Clicking GHC shows me some “recent commits”. The first > three are from a few hrs ago; then the next is 8 days ago. Can’t be > right! It only shows interesting commits. Interesting ones are the most recent ones and all with significant changes. If you want to see all, press the “=” button in the top-right corner. > · There is no key to tell me what the little symbols mean – I > may have known once but I don’t know. A key would be terrific, or > even a link to a key. The symbols next to the three numbers on the right in the table? They are: * number of benchmarks * number of benchmarks improved * number of benchmarks regressed Maybe I should remove the first one, it is not very useful Hovering these icons show you which benchmarks changed, and by how much. > · Clicking on the offending patch (which does show), I see > the n-body complaint, which is good. But there is also > “testsuite/unexpected stats, which is mysterious… clicking on it > yields no more info. There is a “view buildlog” link that I use to investigate such cases. It goes to https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/751996e90a9… which shows bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T13056(optasm) bytes allocated: 440548592 +/-5% Lower bound T13056(optasm) bytes allocated: 418521162 Upper bound T13056(optasm) bytes allocated: 462576022 Actual T13056(optasm) bytes allocated: 417666128 Deviation T13056(optasm) bytes allocated: -5.2 % *** unexpected stat test failure for T13056(optasm) Probably some creep, given how close it is to cut-off percentage. According to https://perf.haskell.org/ghc/#graph/tests/alloc/T13056 this has been stable in the last 50 commits (sorry, still no way to view these graph for any other time interval). > · If compile times went up, would that show up anywhere > (except in testsuite results)? Only if it changes the total time of running make, or if it affects the allocations of a compiler perf test case. We currently have no reliable compilation time benchmarks (which would require _compiling_ stuff NofibRun times). Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2