- ghc-devs - Haskell.org

pull failing due to deleted .buildinfo files
by Simon Marlow 25 Oct '13

25 Oct '13

I just tried to pull into my tree, and encountered several failures of this kind: == libraries/process: running git pull --rebase Cannot pull with rebase: You have unstaged changes. Please commit or stash them. But I have made no local changes, at least not on purpose. Git reports that: # Changes not staged for commit: # deleted: process.buildinfo I know how to revert this and keep going, but it seems that the build shouldn't be deleting files in the repo. Anyone know anything about this? Cheers, Simon

2 2

hoopl questions
by Brett Letner 24 Oct '13

24 Oct '13

Hi all - Some (beginner) hoopl questions: 1) There doesn't seem to be a "run" function or a way to create FuelMonads. I found runWithFuel, getFuel and setFuel, but they are in the hidden Compiler.Hoopl.Fuel module. This is ghc version 7.6.3 and hoopl version 3.9.0 2) Are there any examples that show "inlining" empty graphs/blocks? Suppose I have a C C graph that looks like this: label 12: goto 13; I'd like to rewrite all the occurrences of label 12 to label 13 and eliminate the label 12 graph (from what I've seen this will happen automatically once all the label 12 references are gone). 3) How about inlining single use graphs? Suppose I have two C C graphs that look like this: label 15: <nodes O O> goto 16; label 16: <nodes O O> <node O C> If the only reference to label 16 is from the label 15 graph, then I'd like to rewrite it as: label 15: <nodes O O from label 15> <nodes O O from label 16> <node O C from label 16> Thanks, Brett

4 5

RE: FW: can't make build fail
by Simon Peyton-Jones 23 Oct '13

23 Oct '13

Yes, I can reproduce it now. good. I'm on the trail. It's to do with the AMP warnings! | -----Original Message----- | From: Austin Seipp [mailto:aseipp@pobox.com] | Sent: 23 October 2013 17:13 | To: Simon Peyton-Jones | Subject: Re: FW: can't make build fail | | Simon, | | Strangely I can also not trigger this bug on my machine with validate! | BUT I can trigger it with a normal build! | | For example, this passes: | | $ CPUS=10 sh ./validate | | But this *does* | | $ make distclean && make maintainer-clean && ./boot&& ./configure && | make -j10 | | with a non-specified mk/build.mk (i.e. right after a fresh clone.) | | Can you perhaps try building this way on snake.foxdie.org? | | On Wed, Oct 23, 2013 at 6:22 AM, Simon Peyton-Jones | <simonpj(a)microsoft.com> wrote: | > Austin, (or anyone else) | > | > #8320 is urgent, but I can’t debug it if I can’t reproduce it. You | can | > reproduce it. Can you help me do so? | > | > | > | > Simon | > | > | > | > From: Simon Peyton-Jones | > Sent: 22 October 2013 08:08 | > To: Austin Seipp | > Subject: can't make build fail | > | > | > | > Austin | > | > I have just done a vanilla “sh validate” on snake.foxdie.org, and it | worked | > fine. Haddock docs were built. | > | > So I can’t reproduce the failure #8320 on the very same machine that | you get | > the failure. That’s weird. You could sudo to me and try in | ~/code/HEAD. | > | > I didn’t make a mk/validate.mk file, so I’m just using the underlying | > mk/validate-settings.mk | > | > Can’t debug till I can reproduce! | > | > Thanks | > | > Simon | > | > | > | > Microsoft Research Limited (company number 03369488) is registered in | > England and Wales | > | > Registered office is at 21 Station Road, Cambridge, CB1 2FB | > | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | | | -- | Regards, | Austin - PGP: 4096R/0x91384671

1 0

ghci tests failing with role outputs
by Richard Eisenberg 23 Oct '13

23 Oct '13

Hi all, The recent spate of commits that I've pushed change the default roles assigned to classes. Accordingly, I also changed the filter used within ghci only to print out role information when it differs from the default. However, if you've incorporated my commits but haven't updated your libraries, you'll get failures in ghci tests, as the roles in your built libraries won't correspond to the new defaults. These errors are harmless, and it's safe to continue to use the old roles in your compiled libraries. But, if you want clean tests, you will have to recompile the libraries, and then everything will line up again. Richard

1 0

Re: Why do we put GMP allocations on GHC heaps?
by Austin Seipp 23 Oct '13

23 Oct '13

On Wed, Oct 23, 2013 at 12:03 PM, Gergely Risko <gergely(a)risko.hu> wrote: > On Wed, 23 Oct 2013 11:49:00 -0500, Austin Seipp <austin(a)well-typed.com> writes: > >> $ ghc foo.hs >> $ ghc -integer-type=gmp foo.hs >> $ ghc -integer-type=openssl foo.hs >> $ ghc -integer-type=simple foo.hs > > Well, I didn't think of this. This would indeed be very cool, > unfortunately it's quite hard if I understood you correctly. > >> As an example, libtomcrypt is damn fast, BSD3 licensed, very small, >> and well-respected. Why don't we: >> >> 1) Take libtomcrypt, modify the symbol names to be private to GHC >> (e.g. prefix everything with `ghc_integer_`) - this means the symbol >> names will be internal to GHC, so this also doesn't affect relinks >> against other copies of libtomcrypt (many projects include their own >> copy.) It is so small it basically comes under our control completely. >> >> 2) We can then offer people a integer-tomcrypt which does not have >> compatibility issues, and does not cause as much pain as the >> integration of widely deployed libraries like GMP/OpenSSL, which are >> in various use by many Haskell packages already. >> >> This should give us the flexibility of integer-simple without >> compromising so much on the efficiency aspect. >> >> This is also a very half-baked idea, but just a suggestion. I'd love a >> more modular solution to Integer as well, as I know many other people >> would. > > Just to be sure I understand the idea: do you mean linking this > ghc_integer_ prefix libtommath statically into ghc and every resulting > haskell binary, right? It makes no sense to link dynamically if the > user can't replace it with a standard libtommath anyways because of the > prefix. Basically, yes. Well, it can also be in a dynamic shared library too (for example, a Haskell library libhsinteger-tommath.so or whatever) - but it's more important for static linking, where we do not want conflicts with other instances. In particular, tommath is used quite a bit and it's small enough people tend to just include copies of it wholesale in their project. So linking -static could actually be a problem in some cases due to this (bringing us back where we started.) The upgrading is not so much a problem, because for dynamically linked Haskell exes, you're probably unlikely to relink them against a new dynamic Haskell library (integer-tommath) anyway, without a recompile. And tommath is small enough It's more about having complete namespace control. > And do you mean shipping this libtommath GHC by default (instead of > integer-simple) and starting to develop an integer-gmp or package on > hackage? > > Gergely > I don't know. :) There are a lot of open questions here, it was just a suggestion of something that A) is not totally inefficient while B) not hurting outside integrations so much. I have no immediate opinions on whether we should gut integer-simple or anything. It seems to work for the cases people want it. At the very least, we want to see what the relative speed between the three is. I think this can be done already by writing a wrapper around tommath in Haskell, and then benchmarking between -simple, -gmp and tommath. If tommath is portable and considerably faster than -simple, then that option of gutting it can be on the table, but I see no rush to do this. The question of switching defaults from GMP to something like this also depends on the benchmarks, really. But again I see no reason to rush this, we should obviously compile some evidence to support the theory first. I should also note there is also TomsFastMath by the same author, which is basically libtommath but with optional support for inline assembly on a variety of architectures (including all the ones we support :) It also still provides a mostly compatible API - and the web page already says TomsFastMath is faster than OpenSSL on amd64 :) -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

FW: can't make build fail
by Simon Peyton-Jones 23 Oct '13

23 Oct '13

Austin, (or anyone else) #8320 is urgent, but I can't debug it if I can't reproduce it. You can reproduce it. Can you help me do so? Simon From: Simon Peyton-Jones Sent: 22 October 2013 08:08 To: Austin Seipp Subject: can't make build fail Austin I have just done a vanilla "sh validate" on snake.foxdie.org, and it worked fine. Haddock docs were built. So I can't reproduce the failure #8320 on the very same machine that you get the failure. That's weird. You could sudo to me and try in ~/code/HEAD. I didn't make a mk/validate.mk file, so I'm just using the underlying mk/validate-settings.mk Can't debug till I can reproduce! Thanks Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

1 0

Re: [commit: testsuite] master: Update performance test due to fix for #8456 (1e31b00)
by Simon Marlow 23 Oct '13

23 Oct '13

On 18/10/2013 18:21, git(a)git.haskell.org wrote: > @@ -259,13 +261,15 @@ test('T783', > # 2012-10-08: 226907420 (x86/Linux) > # 2013-02-10: 329202116 (x86/Windows) > # 2013-02-10: 338465200 (x86/OSX) > - (wordsize(64), 640324528, 10)]), > + (wordsize(64), 734038080, 10)]), > # prev: 349263216 (amd64/Linux) > # 07/08/2012: 384479856 (amd64/Linux) > # 29/08/2012: 436927840 (amd64/Linux) > # 12/11/2012: 640324528 (amd64/Linux) > # (OldCmm removed: not sure why this got worse, the > # other perf tests remained about the same) > + # 18/10/2013: 734038080 (amd64/Linux) > + # (fix for #8456) Yikes! 10% just for that change to CmmContFlowOpt? Are you sure? Cheers, Simon

1 0

small hiccup in new GND check
by Richard Eisenberg 22 Oct '13

22 Oct '13

Hi all, The implementation of the new GND check is done and was rather straightforward. But, it brings up a new design issue: With the old check, a writer of a class C could say `type role C nominal` to prevent GND use with that class. Now, all classes have nominal parameters, and there is no (clean) way for a class writer to stop the use of GND. Perhaps this is OK -- classes can't in general be abstract -- but I thought we should pause a moment to reflect on this consequence of the design. For the curious, you can see the code in my github fork at https://raw.github.com/goldfirere/ghc/master/compiler/typecheck/TcDeriv.lhs (search for `role_errs`). An example of the new error message is in https://github.com/goldfirere/testsuite/blob/master/tests/roles/should_fail… I'm running further tests now, so wibbles to the above may happen. Richard

3 3

Always false stack checks are not eliminated - fix on the way
by Jan Stolarek 21 Oct '13

21 Oct '13

Hi guys, I accidentally introduced a bug in one of my recent commits ( 94125c97e49987e91fa54da6c86bc6d17417f5cf): stack checks of the form if (Sp < SpLim) goto cUP; else goto cUQ; are not eliminated in the Cmm. I have a fix, but need to validate it and update the comments. It will be ready tomorrow. Janek

2 3

Significant size increase in GHC HEAD's static library sizes
by Herbert Valerio Riedel 21 Oct '13

21 Oct '13

Hello * While generating .deb packages of various GHC 7.x releases[1] I noticed a peculiar jump in the resulting binary .deb package for GHC HEAD (about +50% wrt to GHC 7.6.3); at first I thought this was mostly due to having enabled shared libaries for that particular package, but then I compared the .a sizes, and noticed some significant increases in object sizes: For instance, Cabal's library file jumps to: 24M ghc-6.12.3/Cabal-1.8.0.6/libHSCabal-1.8.0.6.a 27M ghc-7.0.4/Cabal-1.10.2.0/libHSCabal-1.10.2.0.a 28M ghc-7.2.2/Cabal-1.12.0/libHSCabal-1.12.0.a 27M ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0.a 28M ghc-7.6.3/Cabal-1.16.0/libHSCabal-1.16.0.a 41M ghc-7.7.20131018/Cabal-1.18.1.1/libHSCabal-1.18.1.1.a A similiar increase can be observed for the ghc library: 56M 6.12.3/lib/ghc-6.12.3/ghc-6.12.3/libHSghc-6.12.3.a 65M 7.0.4/lib/ghc-7.0.4/ghc-7.0.4/libHSghc-7.0.4.a 73M 7.2.2/lib/ghc-7.2.2/ghc-7.2.2/libHSghc-7.2.2.a 78M 7.4.2/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2.a 76M 7.6.3/lib/ghc-7.6.3/ghc-7.6.3/libHSghc-7.6.3.a 103M head/lib/ghc-7.7.20131018/ghc-7.7.20131018/libHSghc-7.7.20131018.a But there are other libraries, such as `base` that don't show this kind of size increase. I haven't had time to investigate, but I wanted to report my observation in case somebody has an explanation for this. [1]: https://launchpad.net/~hvr/+archive/ghc Cheers, hvr

2 1