January 2014 - ghc-devs

Quick code style question: Wild card binders
by Joachim Breitner 14 Jan '14

14 Jan '14

Hi, both work, so it is a matter of style, and I’m not sure which one is better style: If I generate a Case where the case binder is not used, should I * use the wildcard binder (mkWildCase), to be explicit about the fact fact that the wildcard binder is unused, or should I * generate a new Unique and a new Id nevertheless, because wildCard is bad? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

1 1

Enable TypeHoles by default?
by Krzysztof Gogolewski 13 Jan '14

13 Jan '14

Hello, I propose to enable -XTypeHoles in GHC by default. Unlike other -X* flags, holes do not really change meaning of the program, they only change error messages. Instead of "_x not in scope", we effectively get "_x not in scope, its expected type is a -> a". You get it only if you precede the identifier not in scope with underscore, so in some sense you declare the intention of using holes. Two possible issues: (a) If you use -fdefer-type-errors, then a program might compile, while previously it did not. However, we should facilitate compiling with defer-type-errors, so I don't think this is a disadvantage. (b) The identifier _ becomes both a pattern and a hole by default, which might confuse new users. Reply: I have never seen anyone ask why code such as "Just _ -> _" does not work. IMO the productivity boost by having holes by default outweighs those two objections. I am open to hearing any other possible issues others might find. The change is trivial implementation-wise; add Opt_TypeHoles to the list in languageExtensions Nothing in DynFlags. -KG

9 11

High-level Cmm code and stack allocation
by Herbert Valerio Riedel 13 Jan '14

13 Jan '14

Hello, According to Note [Syntax of .cmm files], | There are two ways to write .cmm code: | | (1) High-level Cmm code delegates the stack handling to GHC, and | never explicitly mentions Sp or registers. | | (2) Low-level Cmm manages the stack itself, and must know about | calling conventions. | | Whether you want high-level or low-level Cmm is indicated by the | presence of an argument list on a procedure. However, while working on integer-gmp I've been noticing in integer-gmp/cbits/gmp-wrappers.cmm that even though all Cmm procedures have been converted to high-level Cmm, they still reference the 'Sp' register, e.g. #define GMP_TAKE1_RET1(name,mp_fun) \ name (W_ ws1, P_ d1) \ { \ W_ mp_tmp1; \ W_ mp_result1; \ \ again: \ STK_CHK_GEN_N (2 * SIZEOF_MP_INT); \ MAYBE_GC(again); \ \ mp_tmp1 = Sp - 1 * SIZEOF_MP_INT; \ mp_result1 = Sp - 2 * SIZEOF_MP_INT; \ ... \ So is this valid high-level Cmm code? What's the proper way to allocate Stack (and/or Heap) memory from high-level Cmm code? Cheers, hvr

5 19

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 12 Jan '14

12 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