April 2017 - ghc-devs

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

[ANNOUNCE] GHC 8.2.1 release candidate 1
by Ben Gamari 03 Oct '17

03 Oct '17

Hello everyone, The GHC team is very pleased to announce the first candidate of the 8.2.1 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.1-rc1/ This is the first of a few release candidates leading up the final 8.2.1 release. This release will feature, * A new type-indexed Typeable implementation * The long awaited Backpack * Deriving strategies for disambiguating DeriveAnyClass, GeneralizedNewtypeDeriving, and stock mechanisms * Overloaded record fields * Improved compiler performance * Better code generation through more robust tracking of join points * Compact regions for more efficient garbage collection and serialization * Better support for machines with non-uniform memory architectures * More robust support for levity (e.g. RuntimeRep) polymorphism * A simple interface for streaming eventlog data from live processes * Further refinement of DWARF support Unfortunately there are still a few known issues in this release, including a few compiler panics (#13233, #13509) and a memory leak in the simplifier (#13426) which may adversely affect heap sizes and compilation time for some modules. This memory leak unfortunately made it impossible to provide a 32-bit Windows distribution for this candidate; this will be resolved in -rc2. As always, please let us know if you have difficulty. Thanks to everyone who has contributed to this release! Happy testing, - Ben

5 15

can't validate on Linux
by Richard Eisenberg 09 Jul '17

09 Jul '17

Hi devs, When I try validating my patch, validation fails with > ... > Registering library for ghc-prim-0.5.0.0.. > ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install > dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error: > ghc-pkg: Couldn't open database /home/rae/ghc/ghc-valid/bindisttest/install > dir/lib/ghc-8.3.20170312/package.conf.d for modification: {handle: > /home/rae/ghc/ghc-valid/bindisttest/install > dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock}: hLock: invalid > argument (Bad file descriptor) > make[3]: *** [ghc.mk:990: install_packages] Error 1 > make[2]: *** [Makefile:51: install] Error 2 > make[1]: *** [bindisttest/ghc.mk:33: test_bindist] Error 2 > make: *** [Makefile:127: test_bindist] Error 2 Any advice? Thanks! Richard

5 7

Cross-compiling Template Haskell via -fexternal-interpreter and IPC
by Alberto Valverde 30 May '17

30 May '17

Hello, I'm trying to put together a GHC 8.0.1 cross-compiler with Template Haskell support. Initially to target Windows (32bits) from a Linux host but a similar procedure should enable to target other platforms too. I'd like to contribute the patches back so I'm asking for advice on how to implement it in order to increase the chances of them being accepted. I've managed to get a working stage 1 cross-compiler with some patches which correctly builds all stage1 libs and GHC + stage 2 compiler and ghc-iserv.exe. However, compiling TH by using wine and ghc-iserver.exe fails because the file descriptor ids that GHC passes as arguments to "wine ghc-iserv.exe" don't make sense in the emulated windows world. I've hacked around this to test the feasibility of the approach by using stdin/stdout instead of creating new pipes and, surprisingly, managed to cross-compile a simple Template Haskell program. I'm considering using a socket for communicating between both processes as a more permanent solution but this would incur in a dependency on the "network" package. Would this be acceptable? Named pipes have also crossed my mind but I'm not sure how well they're supported by wine. Thanks for your attention. Alberto P.S: Code is in the "cross-mingw-hacks" branches of these repositories and is based on the ghc-8.0.1-release tag: https://github.com/albertov/ghc https://github.com/albertov/hsc2hs A Docker image script here that builds it is here: https://github.com/albertov/ghc-cross-compiler-windows-x86

6 11

GHC 8.0.1-rc4 source tarball availability
by Ben Gamari 14 May '17

14 May '17

tl;dr: If you would like to produce a binary distribution for GHC 8.0.1-rc4 then let us know, grab the source distribution and start building. The binary distributions will be all released one week from today. Hello GHC packagers, I am happy to announce the release of the 8.0.1-rc4 source distribution to binary packagers. This release should resolve all of the issues noted in the release candidate 3 announcement. You will find the usual artifacts at http://downloads.haskell.org/~ghc/8.0.1-rc4/ For this candidate we are again following our new release policy [1], with a one-week delay between the release of the source and binary distributions. The goal of this policy is to give all platforms the opportunity for support from the first day of a release. If all of the expected binary releases are submitted before the week-long delay has elapsed, we will move forward with the release of the binaries on an accelerated schedule. It would be appreciated if you could reply to this message confirming that you intend to offer a binary distribution this release. Otherwise, let either Austin or I know if you have any trouble building your distribution. I have yet to push the ghc-8.0.1-rc4 tag in case we encounter unexpected issues but all of my builds with this tarball thusfar have gone quite well. Good luck and thanks for all of your work! Cheers, - Ben [1] https://mail.haskell.org/pipermail/ghc-devs/2016-March/011546.html

12 75

GHC cross compilation survey
by Moritz Angermann 10 May '17

10 May '17

Dear friends, as some of you might have noticed, together with obsidian.systems, I’m trying to make cross compiling GHC a bit easier. To that extend, I’d like to invite you to fill out a short survey[1], so we understand the needs of the community better. Please follow the attached link and fill out the survey! Cheers, Moritz [1]: https://medium.com/@zw3rk/hello-world-a-cross-compilation-survey-890cb95029…

1 1

[ANNOUNCE] GHC tarballs for Windows 10 Creators Update
by Ben Gamari 02 May '17

02 May '17

Hello GHC users, Over the next few weeks Microsoft will be pushing out an update (the so-called Creators Update) to Windows 10 which will break the GCC toolchain shipped with all GHC releases prior to the yet-to-be-released 8.2.1 (see Trac [1] for details). Over the last few weeks our resident Windows expert Tamar and I have been working on preparing a set of patched Windows tarballs with retrofitted GCC toolchains covering GHC 7.2.1 through 8.0.2. These tarballs are now available on downloads.haskell.org. The new tarballs are distinguished from the original releases with a `-win10` suffix. For instance, the 64-bit 8.0.2 binary distribution can be found at, https://downloads.haskell.org/~ghc/8.0.2/ghc-8.0.2-x86_64-unknown-mingw32-w… Other than an updated mingw/bin/gcc.exe, these are identical to the original releases. More details about the patched toolchain can be found in Tamar's ghc-compat repository [2]. As always, let me know if you encounter trouble. Finally, we should all thank Tamar for his work on this; without his effort GHC-on-Windows would be in a sad state indeed. Thanks Tamar! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/ticket/13411 [2] https://github.com/Mistuke/ghc-compat

5 6

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