- ghc-devs - Haskell.org

Folding constants for floats
by Kyle Van Berendonck 14 Jan '14

14 Jan '14

Hi, I'm cutting my teeth on some constant folding for floats in the cmm. I have a question regarding the ticket I'm tackling: Should floats be folded with infinite precision (and later truncated to the platform float size) -- most useful/accurate, or folded with the platform precision, i.e. double, losing accuracy but keeping consistent behaviour with -O0 -- most "correct"? I would prefer the first case because it's *much* easier to implement than the second, and it'll probably rot less. Regards.

4 12

Fwd: Re: Pattern synonyms for 7.8?
by Dr. ÉRDI Gergő 14 Jan '14

14 Jan '14

Hi, How do I get permissions to push to my wip branch? Thanks, Gergo ---------- Forwarded message ---------- From: "Dr. ERDI Gergo" <gergo(a)erdi.hu> Date: Jan 13, 2014 8:12 PM Subject: Re: Pattern synonyms for 7.8? To: <austin(a)well-typed.com> Cc: "Gabor Greif" <ggreif(a)gmail.com> (removing Mateusz and ghc-devs from the recipient list) Hi, On Mon, 13 Jan 2014, Gabor Greif wrote: From what I understood, you *should* have all permissions to push to > wip/ branches. If not, please contact the admins. (IIRC Austin did > this previously). > OK, I think this was the missing information that got me confused. What repo are we talking about? I tried the mirror on GitHub (git@github.com:ghc/ghc.git) but that one doesn't seem to work: ERROR: Permission to ghc/ghc.git denied to gergoerdi. fatal: Could not read from remote repository. I also tried the Haskell.org repo of ssh://git@git.haskell.org/ghc, but that doesn't work either (which is unsurprising since I don't remember ever sending my SSH public key to haskell.org) 20:10:02 [cactus@galaxy ghc]$ git push -u origin wip/pattern-synonyms Permission denied (publickey). Please advise. Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' Ki volt Casper, mielôtt meghalt?

1 0

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 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