- ghc-devs - Haskell.org

testsuite change
by Simon Peyton Jones 13 Jan '14

13 Jan '14

Herbert I did 'git pull' in my source tree and got the error below. What do I do now? Simon == running git pull remote: Counting objects: 56029, done. remote: Compressing objects: 100% (16843/16843), done. remote: Total 55837 (delta 32572), reused 55743 (delta 32500) Receiving objects: 100% (55837/55837), 6.47 MiB | 2.96 MiB/s, done. Resolving deltas: 100% (32572/32572), completed with 102 local objects. >From git://git.haskell.org/ghc b7ddf63..9c91a24 master -> origin/master Updating b7ddf63..9c91a24 error: The following untracked working tree files would be overwritten by merge: testsuite/.gitignore testsuite/LICENSE testsuite/LICENSE.GPL testsuite/Makefile testsuite/README.md testsuite/config/bad.ps testsuite/config/ghc testsuite/config/good.ps testsuite/driver/runtests.py testsuite/driver/testglobals.py testsuite/driver/testlib.py testsuite/driver/testutil.py testsuite/mk/boilerplate.mk testsuite/mk/ghc-config.hs testsuite/mk/test.mk testsuite/tests/Makefile testsuite/tests/annotations/Makefile testsuite/tests/annotations/should_compile/Makefile testsuite/tests/annotations/should_compile/all.T testsuite/tests/annotations/should_compile/ann01.hs testsuite/tests/annotations/should_compile/ann01.stderr testsuite/tests/annotations/should_fail/Annfail04_Help.hs testsuite/tests/annotations/should_fail/Annfail05_Help.hs testsuite/tests/annotations/should_fail/Annfail06_Help.hs testsuite/tests/annotations/should_fail/Makefile testsuite/tests/annotations/should_fail/all.T testsuite/tests/annotations/should_fail/annfail01.hs testsuite/tests/annotations/should_fail/annfail01.stderr testsuite/tests/annotations/should_fail/annfail02.hs testsuite/tests/annotations/should_fail/annfail02.stderr testsuite/tests/annotations/should_fail/annfail03.hs testsuite/tests/annotations/should_fail/annfail03.stderr testsuite/tests/annotations/should_fail/annfail04.hs testsuite/tests/annotations/should_fail/annfail04.stderr testsuite/tests/annotations/should_fail/annfail05.hs testsuite/tests/annotations/should_fail/annfail05.stderr testsuite/tests/annotations/should_fail/annfail06.hs testsuite/tests/annotations/should_fail/annfail06.stderr testsuite/tests/annotations/should_fail/annfail07.hs testsuite/tests/annotations/should_fail/annfail07.stderr testsuite/tests/annotations/should_fail/annfail08.hs testsuite/tests/annotations/should_fail/annfail08.stderr testsuite/tests/annotations/should_fail/annfail09.hs testsuite/tests/annotations/should_fail/annfail09.stderr testsuite/tests/annotations/should_fail/annfail10.hs testsuite/tests/annotations/should_fail/annfail10.stderr testsuite/tests/annotations/should_fail/annfail11.hs testsuite/tests/annotations/should_fail/annfail11.stderr testsuite/tests/annotations/should_fail/annfail12.hs testsuite/tests/annotations/should_fail/annfail12.stderr testsuite/tests/annotations/should_fail/annfail13.hs testsuite/tests/annotations/should_fail/annfail13.stderr testsuite/tests/annotations/should_run/Annrun01_Help.hs testsuite/tests/annotations/should_run/Makefile testsuite/tests/annotations/should_run/all.T testsuite/tests/annotations/should_run/annrun01.hs testsuite/tests/annotations/should_run/annrun01.stdout testsuite/tests/arityanal/Main.hs testsuite/tests/arityanal/Main.stderr testsuite/tests/arityanal/Makefile testsuite/tests/arityanal/f0.hs testsuite/tests/arityanal/f0.stderr testsuite/tests/arityanal/f1.hs testsuite/tests/arityanal/f1.stderr testsuite/tests/arityanal/f10.hs testsuite/tests/arityanal/f10.stderr testsuite/tests/arityanal/f11.hs testsuite/tests/arityanal/f11.stderr testsuite/tests/arityanal/f12.hs testsuite/tests/arityanal/f12.stderr testsuite/tests/arityanal/f13.hs testsuite/tests/arityanal/f13.stderr testsuite/tests/arityanal/f14.hs testsuite/tests/arityanal/f14.stderr testsuite/tests/arityanal/f15.hs testsuite/tests/arityanal/f15.stderr testsuite/tests/arityanal/f2.hs testsuite/tests/arityanal/f2.stderr testsuite/tests/arityanal/f3.hs testsuite/tests/arityanal/f3.stderr testsuite/tests/arityanal/f4.hs testsuite/tests/arityanal/f4.stderr testsuite/tests/arityanal/f5.hs testsuite/tests/arityanal/f5.stderr testsuite/tests/arityanal/f6.hs testsuite/tests/arityanal/f6.stderr testsuite/tests/arityanal/f7.hs testsuite/tests/arityanal/f7.stderr testsuite/tests/arityanal/f8.hs testsuite/tests/arityanal/f8.stderr testsuite/tests/arityanal/f9.hs testsuite/tests/arityanal/f9.stderr testsuite/tests/arityanal/prim.hs testsuite/tests/arityanal/prim.stderr testsuite/tests/array/Makefile testsuite/tests/array/shou Aborting git failed: 256 at ./sync-all line 120. == Checking for old haddock repo == Checking for old binary repo == Checking for old mtl repo == Checking for old Cabal repo == Checking for old time from tarball == Checking for obsolete Git repo URL simonpj@cam-05-unx:~/code/HEAD-2$

2 4

Alex unicode trick
by Mateusz Kowalczyk 13 Jan '14

13 Jan '14

Greetings, When looking at the GHC lexer (Lexer.x), there's: > $unispace = \x05 -- Trick Alex into handling Unicode. See alexGetChar. > $whitechar = [\ \n\r\f\v $unispace] > $white_no_nl = $whitechar # \n > $tab = \t Scrolling down to alexGetChar and alexGetChar', we see the comments: > -- backwards compatibility for Alex 2.x > alexGetChar :: AlexInput -> Maybe (Char,AlexInput) > > -- This version does not squash unicode characters, it is used when > -- lexing strings. > alexGetChar' :: AlexInput -> Maybe (Char,AlexInput) What's the reason for these? I was under the impression that since 3.0, Alex has natively supported unicode. Is it just dead code? Could all the hex $uni* functions be removed? If not, why not? -- Mateusz K.

4 5

Starting GHC development.
by Chris Heller 13 Jan '14

13 Jan '14

Hello GHC devs. It's been my New Year's resolution to stop being just a GHC user and become a GHC developer. To that end, I've submitted my first patch to GHC (trac #8475 -- just a simple documentation fix). Nothing too earth shattering, but I figured this would be a good way to familiarize myself with the GHC workflow. I believe I've followed the instructions for working on GHC correctly. Please let me know if I have strayed. Looking forward to many more commits in the future. Happy New Year. Chris Heller

8 12

RE: [commit: packages/integer-gmp] wip/T8647: Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type (20d7bfd)
by Simon Peyton Jones 13 Jan '14

13 Jan '14

Would it be worth adding some info from the commit message to the comment with type MPZ#? In particular, the little table you give in the commit message is helpful, but someone looking at the code won't see it. This is subtle stuff. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 12 January 2014 23:37 | To: ghc-commits(a)haskell.org | Subject: [commit: packages/integer-gmp] wip/T8647: Allocate initial 1- | limb mpz_t on the Stack and introduce MPZ# type (20d7bfd) | | Repository : ssh://git@git.haskell.org/integer-gmp | | On branch : wip/T8647 | Link : | http://ghc.haskell.org/trac/ghc/changeset/20d7bfdd29917f5a8b8937fba9b724 | f7e71cd8dd/integer-gmp | | >--------------------------------------------------------------- | | commit 20d7bfdd29917f5a8b8937fba9b724f7e71cd8dd | Author: Herbert Valerio Riedel <hvr(a)gnu.org> | Date: Thu Jan 9 00:19:31 2014 +0100 | | Allocate initial 1-limb mpz_t on the Stack and introduce MPZ# type | | We now allocate a 1-limb mpz_t on the stack instead of doing a more | expensive heap-allocation (especially if the heap-allocated copy | becomes | garbage right away); this addresses #8647. | | In order to delay heap allocations of 1-limb `ByteArray#`s instead | of | the previous `(# Int#, ByteArray# #)` pair, a 3-tuple | `(# Int#, ByteArray#, Word# #)` is returned now. This tuple is given | the | type-synonym `MPZ#`. | | This 3-tuple representation uses either the 1st and the 2nd element, | or | the 1st and the 3rd element to represent the limb(s) (NB: undefined | `ByteArray#` elements must not be accessed as they don't point to a | proper `ByteArray#`, see also `DUMMY_BYTE_ARR`); more specifically, | the | following encoding is used (where `⊥` means undefined/unused): | | - (# 0#, ⊥, 0## #) -> value = 0 | - (# 1#, ⊥, w #) -> value = w | - (# -1#, ⊥, w #) -> value = -w | - (# s#, d, 0## #) -> value = J# s d | | The `mpzToInteger` helper takes care of converting `MPZ#` into an | `Integer`, and allocating a 1-limb `ByteArray#` in case the | value (`w`/`-w`) doesn't fit the `S# Int#` representation). | | The following nofib benchmarks benefit from this optimization: | | Program Size Allocs Runtime Elapsed TotalMem | ------------------------------------------------------------------ | bernouilli +0.2% -5.2% 0.12 0.12 +0.0% | gamteb +0.2% -1.7% 0.03 0.03 +0.0% | kahan +0.3% -13.2% 0.17 0.17 +0.0% | mandel +0.2% -24.6% 0.04 0.04 +0.0% | power +0.2% -2.6% -2.0% -2.0% -8.3% | primetest +0.1% -17.3% 0.06 0.06 +0.0% | rsa +0.2% -18.5% 0.02 0.02 +0.0% | scs +0.1% -2.9% -0.1% -0.1% +0.0% | sphere +0.3% -0.8% 0.03 0.03 +0.0% | symalg +0.2% -3.1% 0.01 0.01 +0.0% | ------------------------------------------------------------------ | Min +0.1% -24.6% -4.6% -4.6% -8.3% | Max +0.3% +0.0% +5.9% +5.9% +4.5% | Geometric Mean +0.2% -1.0% +0.2% +0.2% -0.0% | | Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> | | | >--------------------------------------------------------------- | | 20d7bfdd29917f5a8b8937fba9b724f7e71cd8dd | GHC/Integer/GMP/Prim.hs | 88 ++++++++++++------- | GHC/Integer/Type.lhs | 160 +++++++++++++++------------------ | cbits/gmp-wrappers.cmm | 224 +++++++++++++++++++++++++++++++++------- | ------- | 3 files changed, 285 insertions(+), 187 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 | 20d7bfdd29917f5a8b8937fba9b724f7e71cd8dd | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

panic when compiling SHA
by Kazu Yamamoto 13 Jan '14

13 Jan '14

Hi, When I tried to build the SHA library with GHC head on on 32bit Linux, GHC head got panic. GHC 7.4.2 can build SHA on the same machine. Configuring SHA-1.6.1... Building SHA-1.6.1... Failed to install SHA-1.6.1 Last 10 lines of the build log ( /home/kazu/work/rpf/.cabal-sandbox/logs/SHA-1.6.1.log ): Preprocessing library SHA-1.6.1... [1 of 1] Compiling Data.Digest.Pure.SHA ( Data/Digest/Pure/SHA.hs, dist/dist-sandbox-ef3aaa11/build/Data/Digest/Pure/SHA.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.7.20131202 for i386-unknown-linux): regSpill: out of spill slots! regs to spill = 1129 slots left = 677 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug --Kazu

12 32

[PATCH 2/2] fix binary linking errors on Solaris due to misplacing of -Wl, -u, <symbol> option
by Karel Gardas 12 Jan '14

12 Jan '14

--- compiler/main/DriverPipeline.hs | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index 337778e..1c593b6 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1790,7 +1790,16 @@ linkBinary' staticLink dflags o_files dep_packages = do -- HS packages, because libtool doesn't accept other options. -- In the case of iOS these need to be added by hand to the -- final link in Xcode. - else package_hs_libs ++ extra_libs ++ other_flags + else other_flags ++ package_hs_libs ++ extra_libs -- -Wl,-u,<sym> contained in other_flags + -- needs to be put before -l<package>, + -- otherwise Solaris linker fails linking + -- a binary with unresolved symbols in RTS + -- which are defined in base package + -- the reason for this is a note in ld(1) about + -- '-u' option: "The placement of this option + -- on the command line is significant. + -- This option must be placed before the library + -- that defines the symbol." pkg_framework_path_opts <- if platformUsesFrameworks platform -- 1.7.3.2

1 0

[PATCH 1/2] add handling of Solaris linker into SysTools
by Karel Gardas 12 Jan '14

12 Jan '14

--- compiler/main/DynFlags.hs | 1 + compiler/main/SysTools.lhs | 9 +++++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs index 70d2a81..e253bae 100644 --- a/compiler/main/DynFlags.hs +++ b/compiler/main/DynFlags.hs @@ -3721,6 +3721,7 @@ data LinkerInfo = GnuLD [Option] | GnuGold [Option] | DarwinLD [Option] + | SolarisLD [Option] | UnknownLD deriving Eq diff --git a/compiler/main/SysTools.lhs b/compiler/main/SysTools.lhs index 46f8a86..0c86c18 100644 --- a/compiler/main/SysTools.lhs +++ b/compiler/main/SysTools.lhs @@ -638,6 +638,7 @@ neededLinkArgs :: LinkerInfo -> [Option] neededLinkArgs (GnuLD o) = o neededLinkArgs (GnuGold o) = o neededLinkArgs (DarwinLD o) = o +neededLinkArgs (SolarisLD o) = o neededLinkArgs UnknownLD = [] -- Grab linker info and cache it in DynFlags. @@ -676,6 +677,14 @@ getLinkerInfo' dflags = do -- Process the executable call info <- catchIO (do case os of + OSSolaris2 -> + -- Solaris uses its own Solaris linker. Even all + -- GNU C are receommended to configure with Solaris + -- linker instead of using GNU binutils linker. Also + -- all GCC distributed with Solaris follows this rule + -- precisely so we assume here, the Solaris linker is + -- used. + return $ SolarisLD [] OSDarwin -> -- Darwin has neither GNU Gold or GNU LD, but a strange linker -- that doesn't support --version. We can just assume that's -- 1.7.3.2

1 0

Validating with Haddock
by Mateusz Kowalczyk 12 Jan '14

12 Jan '14

Greetings, I'm trying to validate HEAD and I care that Haddock is built alongside it (so --no-haddock is not an option). I get the following errors listed at the bottom of this e-mail. How can I validate so that it all builds? >From what I understand, to validate I should: * Have a stable compiler in my PATH (7.6.3) * go to top level directory * run ‘sh validate’ Am I missing steps? == Start post-build package check Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:00:55 UTC for /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d (same as cache) using cache: /home/shana/.ghc/i386-linux-7.7.20131227/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache Timestamp 2013-12-28 05:22:27 UTC for /home/shana/programming/ghc/inplace/lib/package.conf.d (same as cache) using cache: /home/shana/programming/ghc/inplace/lib/package.conf.d/package.cache There are problems in package xhtml-3000.2.1: dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist There are problems in package ghc-paths-0.1.0.9: dependency "base-4.7.0.0-578628bf142f9304d05ce5581b5f8d76" doesn't exist The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. xhtml-3000.2.1 ghc-paths-0.1.0.9 -- Mateusz K.

5 23

HEADS-UP: testsuite has been folded into ghc; back up your old testsuite/ folder!
by Herbert Valerio Riedel 12 Jan '14

12 Jan '14

Hello *, It's finally done; effective immediately, the testsuite/ folder is now tracked as part of ghc.git (for the master branch) *IMPORTANT* If there's any chance you have something importing lying around in your testsuite/ please move it out of the way preemptively (e.g. with 'mv testsuite/ testsuite-old/') *before* you perform a 'git pull' or 'sync-all pull' on ghc.git. Even though there are some safe-guards in place, those might not be 100% effective, so better safe than sorry. As only the `master` branch of testsuite.git has been merged, those of you who had wip/ branches or similar in testsuite.git need to handle those yourselves. Should you need assistance with bringing over those commits from testsuite.git into ghc.git (or if there's anything else that's now broken because of this change), please let me and/or Austin a line, so we can assist you. See also previous post "Folding ghc/testsuite repos *now*, 2nd attempt"[1] announcing this step. [1] http://www.haskell.org/pipermail/ghc-devs/2014-January/003730.html Greetings, hvr

1 0

Repository Reorganization Question
by Austin Seipp 11 Jan '14

11 Jan '14

Hi all, While discussing something with Herbert this week in preparation of making a new stable branch, he brought a good point to my attention, which is that if we go ahead and reorganize the repository situation post 7.8, merging things to the stable branch from HEAD will become a bit harder. Notably, we had planned to fold testsuite (and perhaps some other repositories) into the GHC tree. Once we do this, the two branches will have diverged quite a bit, so merging from HEAD to STABLE will become harder* (because HEAD would have rolled in testsuite changes for example, but the STABLE branch would not have this history.) Thinking about it, the best time to do such a move is, basically, when there is no active stable branch. Unfortunately this time is right now, but I'm not sure how everyone feels about this. So, the question is: should we go ahead and pull the trigger on some of these perhaps? Herbert collected some numbers on the git repositories and outlined all the basic details here: https://ghc.haskell.org/trac/ghc/wiki/GitRepoReorganization The only thing I'd honestly propose right now is folding 'testsuite' into the main repository, but of course we should see what people think - perhaps we should keep base/etc off the table for now, since they seem more controversial. * I'll point out they will only become *slightly* harder in most cases, because I can always instead apply unified diffs, rather than cherry pick or something. But it does lose the original metadata from commits too. But I won't cry if people vote against this. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

13 43