June 2016 - ghc-devs - Haskell.org

Force GC calls out of the straight line execution path
by Harendra Kumar 17 Jun '16

17 Jun '16

Hi, I noticed in the generated code (llvm as well as native) that in some cases the GC calls are in the straight path and the regular code is out of the straight line path. Like this: => 0x408fc0: lea 0x30(%r12),%rax => 0x408fc5: cmp 0x358(%r13),%rax => 0x408fcc: jbe 0x408fe9 # notice jbe instead of ja i.e. branch taken in normal case I tried to count in how many cases its happening in my executable and found that its only a small percentage (4-6%) of cases but those cases include the code which runs 99% of the time in my benchmark. Though it does not make a whole lot of difference but the difference is perceptible and especially when it is in a tight loop. Is it possible to somehow force all the GC calls out of the line during code generation? Has it been thought/discussed before? -harendra

3 4

ghc-pkg, package database path containing a trailing slash, and ${pkgroot}
by Nicolas Dudebout 16 Jun '16

16 Jun '16

When passing a package database to ghc-pkg via GHC_PACKAGE_PATH or --package-db, ${pkgroot} does not get computed properly if the input path contains a trailing slash. Default behavior: $ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Correct behavior (no trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2" Incorrect behavior (with trailing slash): $ ghc-pkg --package-db /usr/lib/ghc-7.10.2/package.conf.d/ describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" $ GHC_PACKAGE_PATH=/usr/lib/ghc-7.10.2/package.conf.d/ ghc-pkg describe base | grep pkgroot pkgroot: "/usr/lib/ghc-7.10.2/package.conf.d" When this bug happens, ghc-pkg check complains about missing files for packages using ${pkgroot}. This bug happens because ${pkgroot} is computed using takeDirectory. It should instead use (takeDirectory . dropTrailingPathSeparator)

2 1

CoreToStg Asserts
by Phyx 15 Jun '16

15 Jun '16

Hi *, I'm hoping someone could help me understand what the asserts in CoreToStg on line 240 and 216 are trying to tell me. I hit both of them while trying to compile libraries as dyn. WARNING: file compiler\stgSyn\CoreToStg.hs, line 250 $trModule2 False True ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 8.1.20160612 for x86_64-unknown-mingw32): ASSERT failed! file compiler\stgSyn\CoreToStg.hs line 216 $trModule2 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug WARNING: file compiler\simplCore\SimplCore.hs, line 633 Simplifier bailing out after 4 iterations [6737, 736, 51, 9] Size = {terms: 12,990, types: 9,998, coercions: 443} WARNING: file compiler\stgSyn\CoreToStg.hs, line 250 $fEqBigNat_$c/= False True ghc-stage1.exe: panic! (the 'impossible' happened) (GHC version 8.1.20160612 for x86_64-unknown-mingw32): ASSERT failed! file compiler\stgSyn\CoreToStg.hs line 240 [$fEqBigNat_$c/=, $fEqBigNat] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Kind Regards, Tamar

4 4

Re: ghc-pkg, package database path containing a trailing slash, and ${pkgroot}
by Ryan Scott 15 Jun '16

15 Jun '16

Good catch! This seems like a straightforward bug. Do you mind creating a ticket for this issue on GHC Trac at https://ghc.haskell.org/trac/ghc/newticket ? Best, Ryan S.

1 0

Pusing to haddock
by Simon Peyton Jones 14 Jun '16

14 Jun '16

Devs, I want to push to the haddock repo, to fix the build. But I can’t. .git/modules/utils/haddock/ contains [remote "origin"] url = git://git.haskell.org/haddock.git pushurl = ssh://git@git.haskell.org/haddock.git fetch = +refs/heads/*:refs/remotes/origin/* I’m on branch ghc-head. But when I push I get /cygdrive/c/code/HEAD/utils/haddock$ git push remote: W refs/heads/ghc-head haddock simonpj DENIED by refs/.* remote: error: hook declined to update refs/heads/ghc-head To ssh://git@git.haskell.org/haddock.git ! [remote rejected] ghc-head -> ghc-head (hook declined) error: failed to push some refs to 'ssh://git@git.haskell.org/haddock.git' No info on WHY it rejected. What now? I attach the patch if someone else would like to push. If you do, update ghc HEAD to match Simon

5 8

haddock
by Simon Peyton Jones 13 Jun '16

13 Jun '16

Ah! I forgot to push a one-line difff to haddock, which is breaking the build. Sorry. Gotta go right now but will do tonight. Meanwhile all should be ok if you swtich off Haddock Simon

1 0

Why upper bound version numbers?
by Dominick Samperi 10 Jun '16

10 Jun '16

Why would a package developer want to upper bound the version number for packages like base? For example, the clash package requires base >= 4.2 && base <= 4.3 Consequently, it refuses to install with the latest ghc provided with the Haskell Platform (8.0.1). Does this mean that assuming that future versions of the platform will remain backwards compatible with prior versions is unsafe? Thanks, Dominick

12 19

cpphs bug with pathnames beginning with more than one slash
by Dan Aloni 09 Jun '16

09 Jun '16

Hi Malcolm, If we pass pathnames starting with more than one slash to '-include', cpphs generates invalid output. These are valid UNIX pathnames. I've tested with version 1.20.1 on Linux. Example: $ touch empty.hs $ cpphs --cpp -include //dev/null empty.hs #line 1 "test.hs" #line 1 " #line 2 "test.hs" #line 1 "test.hs" If I remove the extra '/', I get a good output: $ touch empty.hs $ cpphs --cpp -include /dev/null empty.hs #line 1 "test.hs" #line 1 "/dev/null" #line 2 "test.hs" #line 1 "test.hs" Thanks. -- Dan Aloni

2 2

Re: Why upper bound version numbers?
by Jeremy . 09 Jun '16

09 Jun '16

Versions of package dependencies can be categorised into 5 sets: D1) Versions which the maintainer has tested and found to work D2) Versions which the maintainer has not tested but expects to work D3) Versions which the maintainer has tested and found to not work D4) Versions which the maintainer has not tested but expects to not work D5) Everything else Cabal, however, only knows of 3 sets: C1) Versions which satisfy build-depends C2) Versions which satisfy build-depends with --allow-newer C3) Everything else The problem arises from the fact that the D sets to not map well onto the C sets, even after combining D1&D2 and D3&D4. Perhaps this could be solved with a new .cabal property, breaks-with. The solver will then prefer packages in this order: 1) Versions that satisfy build-depends 2) Versions that are not in breaks-with, unless a flag such as --strict-build-depends is applied This may also lead to clearer build-depends, as instead of multiple ranges with gaps to skip know broken versions, build-depends can list a single range, and breaks-with can list the bad versions.

2 1

Call for talks: Haskell Implementors Workshop 2016, Sep 24 (FIXED), Nara
by Edward Z. Yang 09 Jun '16

09 Jun '16

(...and now with the right date in the subject line!) Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Joachim Breitner (Karlsruhe Institut für Technologie) * Duncan Coutts (Well Typed) * Michael Snoyman (FP Complete) * Luite Stegeman (ghcjs) * Niki Vazou (UCSD) * Stephanie Weirich (University of Pennsylvania) * Edward Z. Yang - chair (Stanford University)

1 0