- ghc-devs - Haskell.org

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

DeriveFoldable treatment of tuples is surprising
by David Feuer 21 Mar '17

21 Mar '17

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

1 0

Why are there no Show instances for internal types
by Tom Sydney Kerckhove 20 Mar '17

20 Mar '17

Dear GHC Devs, I am trying to use GHC as a library but I'm having a lot of trouble with understanding what everything means. Up to now, I have been able to figure out what to do by reading the sources, but it ocured to me that much of my struggles could have been mitigated if the relevant types had Show instances. I am specifically talking about the types concerning type checking. TypecheckedModule and everything below that. I am aware that most of the types have an Outputable instance, but there are two problems with that: - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace) - These instances are not intended to show the internal structure of a value, but rather a 'human readable' representation of a value. My questions for you: - Is there a reason that there are no derived 'Show' instances for most types? - Would you accept a diff that adds these? Thank you for your time. -- Tom Sydney Kerckhove

8 13