March 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

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

D3316 status
by Ben Gamari 30 Mar '17

30 Mar '17

Hi Richard, It took me a bit longer than expected to get back to D3316 but I think I am now done. It wasn't quite as trivial as I thought it might be, so I thought I would summarize what was needed, 1. tcSplitTyConApp_maybe and tcRepSplitTyConApp_maybe have been moved from TcType to Type to avoid import loops. I'm not terribly happy with this change, but I spent a fair amount of time looking for alternatives and it seems this is the least evil. Moreover, there is precedent for this in tcRepSplitAppTy_maybe. It would be nice to refactor TcType and friends to avoid this loop. 2. TypeMap now respects the Constraint/Type distinction. I believe this is safe for the TypeMap uses in the typechecker itself. The only other use AFAICT is Specialise.CallKeySet, which I believe should also be fine under this change. 3. TcInteract.matchTypeable now handles Constraint explicitly. With all of this the T11715 test passes. I've uploaded my changes relative to your patch as D3396 for your review. However, I am a bit concerned with (2) as it runs contrary to your original implementation, which changed coreViewOneStarKind to coreView. What was the reasoning behind this? The motivation for moving to tcView here is the dictionary cache, which uses a TypeMap. Namely, if we solve for `Typeable Type`, and later look for `Typeable Constraint` in the dictionary cache, we will incorrectly find the `Typeable Type` dictionary. Thoughts? Cheers, - Ben

2 1

GHC 8.2.1 status
by Ben Gamari 28 Mar '17

28 Mar '17

Hello everyone, Here is your periodic release update. After a number of false-starts, the tree is finally approaching a releasable state. Last week I cut the ghc-8.2 branch and things have been stabilizing ever since. At this point we are waiting on only a couple more fixes before the rc1 source release can be cut, * #13474: To be addressed by Richard soon * #13410: To be addressed by Simon PJ shortly * #13333: To be addressed by Ben shortly * #13433: Simon Marow has a fix There are also a few issues that we have deemed not to block -rc1, but which must be addressed prior to the final release, * #13220: David will verify that * #13233: Ben will do a bit more digging, Simon PJ will think about it With luck we will be able to finish the -rc1 blockers in the next couple of days, allowing us to cut a source release by Tuesday or Wednesday. Cheers, - Your friendly release manager

3 3

Re: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)
by Gabor Greif 27 Mar '17

27 Mar '17

This commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29 introduced a compilation failure with gcc4.4 (my gcc). The typedef-name `SectionFormatInfo` is redefined. Here is the reason: http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-erro… I have a fix in testing, will commit shortly. Cheers, Gabor On 3/27/17, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/8ed29b50376856018dfbbcbd6d728c69a… > >>--------------------------------------------------------------- > > commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29 > Author: Moritz Angermann <moritz.angermann(a)gmail.com> > Date: Tue Mar 21 10:59:49 2017 -0400 > > rts linker: Introduce MachOTypes > > This diff introduces MachOTypes, to reduce the need to typing `struct` > all the time. It also coaleces the 64 and non 64 structs. It also adds > additional fiedls to the object code structure for macho, which makes > working with macho object code much simpler and requires less passing > around of variabls or address recomputation for the header, symbol > table, etc... > > Furthermore this diff introduces a type for a linked list of stubs. > > I had to move the #ifdef from the bottom of the file up, to be able to > extend the object code structure conditional on the use of the macho > file format. > > This is just one of the pieces for the rts linker > support for ios (aarch64-macho) > > --- > > The following diagram and legend tries to explain the dependencies a > bit: > ``` > .- D3240 > v > D3255 <- D3252 <- D3251 <- This > ^ > '- D3238 > ``` > > - In D3238 we started allowing preloading object code with mmap > in iOS, where we can't have r+w+x. > - In D3239 we introduced a richer extension of the object code > data type to make working with mach-o files easier. > - In D3240 we set the stage to allow loading archives (.a) on iOS > - In D3251 we added init and deinit functions to populate and > depopulate the enriched object code data structure for mach-o > files. > - In D3252 we refactored most of the MachO.c file to use the > new types and data structure. > - in D3255 we finally introduce the aarch64-mach-o linker. > > Reviewers: austin, erikd, simonmar, rwbarton, bgamari > > Subscribers: rwbarton, thomie, ryantrinkle > > Differential Revision: https://phabricator.haskell.org/D3239 > > >>--------------------------------------------------------------- > > 8ed29b50376856018dfbbcbd6d728c69af0c9f29 > rts/Linker.c | 6 +++ > rts/LinkerInternals.h | 28 +++++++++- > rts/linker/MachOTypes.h | 133 > ++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 165 insertions(+), 2 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc 8ed29b50376856018dfbbcbd6d728c69af0c9f29 > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits >

3 3

SPECIALISE INLINE pragma
by Matthew Pickering 27 Mar '17

27 Mar '17

The user guide says that "you can make GHC diverge by using SPECIALISE INLINE on an ordinarily-recursive function." Does anyone know the ticket or technique which causes this to happen? https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… On the same topic, I also wrote a blog post simply explaining the essential things to know about the inliner and specialiser as I don't think they are generally appreciated. Comments welcome! http://mpickering.github.io/posts/2017-03-20-inlining-and-specialisation.ht… Matt

3 6

Building head on Openbsd
by Adam Steen 27 Mar '17

27 Mar '17

Hi I attempt to build head today on OpenBSD current and failed, but i not sure where to start to fix the problems. The full configure and build logs are attached. Just a note: ghc-8.0 builds fine, ghc-8.2 fails with the same error. the first error is "inplace/bin/ghc-stage1" -optc-std=gnu99 -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Wi nline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedcons tants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc- O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections -optc-fdata-sections -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconsta nts/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wnoncanonical-monad-instances -c rts/Timer.c -o rts/dist/build/Timer.o In file included from rts/posix/Signals.h:13, from rts/RtsSignals.h:14, from rts/Timer.c:26:0: error: /usr/include/signal.h:72:0: error: warning: redundant redeclaration of '__errno' | 72 | extern int *__errno(void); | ^ and the last error is rts/linker/Elf.c:539:0: error: warning: unused variable 'secno' | 539 | Elf_Word secno = stab[j].st_shndx; | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) gmake[1]: *** [rts/ghc.mk:248: rts/dist/build/linker/Elf.o] Error 1 gmake: *** [Makefile:127: all] Error 2

4 5

Polymorphism over unboxed tuples
by Ryan Scott 25 Mar '17

25 Mar '17

Section 4.2 of the paper Levity Polymorphism [1] makes a bold claim about polymorphism for unboxed tuples: Note that this format respects the computational irrelevance of nesting of unboxed tuples. For example, these three types all have the same kind, here written PFP for short: type PFP = TYPE '[PtrRep, FloatRep, PtrRep] (# Int, (# Float#, Bool #) #) :: PFP (# Int, Float#, Bool #) :: PFP (# (# Int, (# #) #), Float#, Bool #) :: PFP But in GHC, that isn't the case! Here's proof of it from a recent GHCi session: GHCi, version 8.3.20170322: http://www.haskell.org/ghc/ :? for help λ> :set -XUnboxedTuples -XMagicHash λ> import GHC.Exts λ> :kind (# Int, (# Float#, Bool #) #) (# Int, (# Float#, Bool #) #) :: TYPE ('TupleRep '['LiftedRep, 'TupleRep '['FloatRep, 'LiftedRep]]) λ> :kind (# Int, Float#, Bool #) (# Int, Float#, Bool #) :: TYPE ('TupleRep '['LiftedRep, 'FloatRep, 'LiftedRep]) λ> :kind (# (# Int, (# #) #), Float#, Bool #) (# (# Int, (# #) #), Float#, Bool #) :: TYPE ('TupleRep '['TupleRep '['LiftedRep, 'TupleRep '[]], 'FloatRep, 'LiftedRep]) As you can see, each of these different nestings of unboxed tuples yields different kinds, so they most certainly do *not* uphold the property claimed in the paper. Is this a bug? Or is there some reason that GHC implemented it differently? Ryan S. ----- [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/levity-…

3 3