- ghc-devs - Haskell.org

trac ticket about missing in tree gmp on newest mac ghc builds
by Carter Schonwald 09 Nov '18

09 Nov '18

hey Ben, HVR https://ghc.haskell.org/trac/ghc/ticket/15769 seems to indicate there was quite a serious faux pas in the mac builds, do you folk need help? -Carter

1 0

StgRhsClosure freevar and argument name duplicates
by Csaba Hruska 07 Nov '18

07 Nov '18

Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) *[occ]* -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry *[bndr]* -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body

2 15

GHC 8.8 freeze in three weeks
by Ben Gamari 05 Nov '18

05 Nov '18

Hello everyone, Incredibly enough we are quickly coming up on three months since the nominal GHC 8.6.1 release date. This means that the GHC 8.8 branch is quickly approaching. We will plan on cutting the branch on November 18th. Note that this is in three weeks. If you have a patch that you would like to see in GHC 8.8 and it isn't yet up on Phabricator, do let me know. Moreover, if you have something that will be in GHC 8.8 and you haven't yet added it to the release status page [1], please add it. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.8.1

2 2

[ANNOUNCE] GHC 8.6.2 is now available
by Ben Gamari 05 Nov '18

05 Nov '18

Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.2, a bugfix release to GHC 8.6.1. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.2 The 8.6 release fixes several regressions present in 8.6.1 including: * A long-standing (but previously hard to manifest) bug resulting in undefined behavior for some applications of dataToTag# has been fixed (#15696) * An incorrect linker path to libgmp in the Mac OS binary distributions (#15404) * A regression rendering Windows installations to read-only directories unusable (#15667) * A regression resulting in panics while compiling some record updates of GADTs constructors (#15499) * A regression resulting in incorrect type errors when splicing types into constraint contexts has been fixed (#15815) * Around a dozen other issues. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.2&col=id…

1 0

multiple top level Main.main binders in STG
by Csaba Hruska 02 Nov '18

02 Nov '18

Hello, I added an STG exporter to my modified GHC to do experiments with the STG representation of the program. I noticed that there are multiple top-level binders for *Main.main* function. Is this a convention or a bug? Regards, Csaba Hruska Here is an example code snippet of the exported STG of the Main module: Main.main2 = closure (F:) (B:) { case Main.$wupto 1# 10000000# of sat.s16537 { DEFAULT -> case Main.$wxsum 0# sat.s16537 of ww.s16538 { DEFAULT -> case GHC.Show.$wshowSignedInt 0# ww.s16538 GHC.Types.[] of ww4.s16539 { GHC.Prim.(#,#) ww5.s16540 ww6.s16541 -> GHC.Types.: ww5.s16540 ww6.s16541 } } }} Main.main1 = closure (F:) (B: void.040) { GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout Main.main2 GHC.Types.True GHC.Prim.void#} *Main.main* = closure (F:) (B: void.040) { Main.main1 GHC.Prim.void#} Main.main3 = closure (F:) (B: void.040) { GHC.TopHandler.runMainIO1 Main.main1 GHC.Prim.void#} *Main.main* = closure (F:) (B: void.040) { Main.main3 GHC.Prim.void#}

2 3

Visible dependent quantification / CUSKs
by Richard Eisenberg 02 Nov '18

02 Nov '18

Hi all, I see visible dependent quantification and top-level kind signatures on the release plan for GHC 8.8. Is there a diff for these I've missed? Or is something in the works? Sorry if I've just missed it go by! Thanks, Richard

2 2

RE: Hadrian build failed
by Andrey Mokhov 01 Nov '18

01 Nov '18

Hello Yotam, Could you please report this as a bug on GHC Trac? https://ghc.haskell.org/trac/ghc/wiki/ReportABug I couldn’t quickly reproduce your issue, however, I run into another seemingly unrelated problem. P.S.: Note that build instructions in my blog post got slightly out of date after the Hadrian move – I’ve fixed this. Cheers, Andrey -------- Forwarded Message -------- Subject: Hadrian build failed Date: Thu, 1 Nov 2018 20:33:14 +0200 From: Yotam Ohad <yotam2206(a)gmail.com><mailto:yotam2206@gmail.com> To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Hi, I'm trying to build with hadrian (https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/) I get an error when running: stack exec hadrian -- --directory ".." -j --flavour=quickest --configure md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. ) Deleting and trying again results in the same error. Any idea on how to solve this? Yotam

1 0

Hadrian build failed
by Yotam Ohad 01 Nov '18

01 Nov '18

Hi, I'm trying to build with hadrian ( https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/) I get an error when running: stack exec hadrian -- --directory ".." -j --flavour=quickest --configure md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. ) Deleting and trying again results in the same error. Any idea on how to solve this? Yotam

1 0

Validating with LLVM
by Travis Whitaker 01 Nov '18

01 Nov '18

Hello GHC Devs, I'm working on a very tiny patch for GHC. The patch concerns the LLVM code generator, and I'd like to run the validate script. ./validate ignores mk/ build.mk (which is probably correct) and it doesn't seem to be using the LLVM backend. LLVM tools are on the PATH; I'm working from the ghc-8.4 branch so I'm using LLVM 5. Is it possible to validate with the LLVM backend? If not, what's considered a sufficiently thorough test? Apologies if I'm missing something obvious. Thanks! Travis

2 1

ghc-in-ghci memory usage
by Matthew Pickering 31 Oct '18

31 Oct '18

I just tried using the ghc-in-ghci script again and it appears that the memory usage problems have been resolved. Probably thanks to Simon Marlow who fixed a lot of space leaks in ghc. A reminder of how to use it: ./utils/ghc-in-ghci/run.sh -j<n> will load ghc into ghci so you can `:r` to recompile when you make a change. Cheers, Matt

3 3