- ghc-devs - Haskell.org

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

Slow validate failures
by Ömer Sinan Ağacan 24 Mar '17

24 Mar '17

Hi all, I have a patch that effects profiling code and I realized neither `./validate --fast` nor `./validate` test the "prof" way so I tried `./validate --slow`. I saw that even on a clean branch I get 250 unexpected failures and 6 unexpected passes. I had a quick look at logs. Most of the failures seem to be in these formats: - Compile failed (exit code 1) errors were: T6005a.hs:1:1: fatal: Cannot load -prof objects when GHC is built with -dynamic To fix this, either: (1) Use -fexternal-interpreter, or (2) Build the program twice: once with -dynamic, and then with -prof using -osuf to set a different object file suffix. - Compile failed (exit code 1) errors were: T5984_Lib.hs:3:8: error: Could not find module ‘Prelude’ Perhaps you haven't installed the "p_dyn" libraries for package ‘base-4.10.0.0’? Use -v to see a list of the files searched for. T5984_Lib.hs:5:1: error: Could not find module ‘Language.Haskell.TH’ Perhaps you haven't installed the "p_dyn" libraries for package ‘template-haskell-2.12.0.0’? Use -v to see a list of the files searched for. But there are also some serious-looking failures, like =====> hpc_fork(hpc) 5717 of 5834 [6, 245, 0] ... +++ "/tmp/ghctest-yrj0el9g/test spaces/../../libraries/ghc-compact/tests/compact_share.run/compact_share.run.stdout.normalised" 2017-03-24 00:38:02.486282332 +0300 @@ -1,4 +1,4 @@ 275599 -3801088 +6291456 275599 -2228224 +3506176 So it seems at this point there's basically no realiable way to test profiling changes. I was wondering if someone here know anything about these. If anyone's interested, I pushed test output of `./validate --slow` here: (9.2M file) https://gist.githubusercontent.com/osa1/7cbcc8303f1e213a10accf0bcd9b5ab2/ra… Ömer

1 0

FYI: removing `fibon`
by Michal Terepeta 22 Mar '17

22 Mar '17

Hi all, I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned upstream (no commits in 5 years) and I'm not aware of anyone using it or working on it. At this point I don't think it makes sense to try to revive it - I'd prefer putting the time/effort into getting a few new benchmarks. There were already discussions about removing it in https://ghc.haskell.org/trac/ghc/ticket/11501 If someone is actually working on getting it to work again, please shout! Thanks, Michal PS. I've tried uploading the patch to Phab, but I think it's just too large (arc is crashing). So I've uploaded it to github: https://github.com/michalt/nofib/tree/fibon

2 2

Re: DeriveFoldable treatment of tuples is surprising
by Ryan Scott 22 Mar '17

22 Mar '17

I believe what Sven was saying is not that the Foldable instance for tuples are given "special treatment" (which is arguably an orthogonal discussion), but rather that -XDeriveFoldable special-cases tuples, which is certainly true. As Edward noted, there is one possible justification for this behavior w.r.t. things like newtype V3 a = V3 (a, a, a) deriving Foldable. But to be honest, I find this justification tenuous at best, given the confusion it causes when explaining how DeriveFunctor/DeriveFoldable/DeriveTraversable work to newcomers. Removing this special case would not only be simple, but it would also lead to a more consistent story overall. I would be curious to know how much code in the wild is actually taking advantage of a trick like newtype V3 a = V3 (a, a, a) deriving Foldable. If the breakage isn't terrible, then I propose we just rip off this wart. (This is basically a rehash of the thoughts I left at https://ghc.haskell.org/trac/ghc/ticket/13465#comment:3) Ryan S.

2 1

Re: DeriveFoldable treatment of tuples is surprising
by David Feuer 22 Mar '17

22 Mar '17

The point is that there are two reasonable ways to do it, and the deriving mechanism, as a rule, does not make choices between reasonable alternatives. On Tue, Mar 21, 2017 at 5:05 PM, Jake McArthur <jake.mcarthur(a)gmail.com> wrote: > I think it's a question of what one considers consistent. Is it more > consistent to treat tuples as transparent and consider every component with > type `a`, or is it more consistent to treat tuples as opaque and reuse the > existing Foldable instance for tuples even if it might cause a compile time > error? > > > On Tue, Mar 21, 2017, 4:34 PM David Feuer <david.feuer(a)gmail.com> wrote: >> >> This seems much too weird: >> >> *> :set -XDeriveFoldable >> *> data Foo a = Foo ((a,a),a) deriving Foldable >> *> length ((1,1),1) >> 1 >> *> length $ Foo ((1,1),1) >> 3 >> >> I've opened Trac #13465 [*] for this. As I write there, I think the >> right thing is to refuse to derive Foldable for a type whose Foldable >> instance would currently fold over components of a tuple other than >> the last one. >> >> I could go either way on Traversable instances. One could argue that >> since all relevant components *must* be traversed, we should just go >> ahead and do that. Or one could argue that we should be consistent >> with Foldable and refuse to derive it. >> >> What do you all think? >> >> [*] https://ghc.haskell.org/trac/ghc/ticket/13465 >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

5 4