September 2013 - ghc-devs

Performance failures
by Jan Stolarek 18 Sep '13

18 Sep '13

I've been getting failures from a few performance test: - haddock.base (stat too good - allocation has decreased). I see that allocation was bumped yesterday by Joachim due to changes in printf implementation. For me this causes a failure. Actual bytes allocated: 6294339840 - T5837. Stat too low - allocation increased. This one is failing on my machine since the AMP patch (BTW. - it only fails durng ./validate, never when run separately). Actual bytes allocated: 90587232. I've adjusted the numbers so that tests pass on my machine, but I expect they might start failing on other systems. If they do, please report in this thread and post numbers that you are getting - we'll try to work out a reasonable average. Janek

1 0

[PATCH 1/2] System.IO.Unsafe: fix doc typo: 'System.IO.IO' to 'System.IO'
by slyich＠gmail.com 18 Sep '13

18 Sep '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- System/IO/Unsafe.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/System/IO/Unsafe.hs b/System/IO/Unsafe.hs index eb6eef6..1971e9f 100644 --- a/System/IO/Unsafe.hs +++ b/System/IO/Unsafe.hs @@ -16,7 +16,7 @@ ----------------------------------------------------------------------------- module System.IO.Unsafe ( - -- * Unsafe 'System.IO.IO' operations + -- * Unsafe 'System.IO' operations unsafePerformIO, unsafeDupablePerformIO, unsafeInterleaveIO, -- 1.8.3.2

3 3

Safe Haskell and abstraction
by Richard Eisenberg 17 Sep '13

17 Sep '13

Hi David, Joachim, Simon, and I have been trying to figure out how roles and newtype coercions fit in with Safe Haskell. (See, for example http://www.haskell.org/pipermail/ghc-devs/2013-September/002526.html, which I will try to summarize here.) It all boils down to this: Does Safe Haskell strive to guarantee that a datatype whose constructors are not visible is actually abstract? With roles implemented, GeneralizedNewtypeDeriving (GND) and the newtype coercions (implemented through a Coercible "class") are fully type-safe. However, there are various ways of using these features to end-run abstraction. I infer from #5498 that Safe Haskell *does* strive to maintain abstraction barriers, and then we need to think hard about how to fit GND and Coercible into Safe Haskell. Bug #5498 demonstrates how GND breaks abstraction (this behavior is unchanged with roles), and here is an example of how Coercible can, too: > module A (Abstract) where > data Abstract a = MkAbs a > > abstractInt :: Int -> Abstract Int > abstractInt = MkAbs > ------ > module B where > import A > import GHC.Prim -- or wherever Coercible lives > > newtype Age = MkAge Int > notSoAbstract :: Abstract Age > notSoAbstract = coerce (abstractInt 5) Does this behavior eliminate the use of `coerce` within Safe Haskell? Does #5498 eliminate GND from Safe Haskell? And, do the fixes proposed in the email thread linked above fix these problems? To wit, under Safe Haskell, we propose that coercions and GND work only when all constructors of the relevant datatype (and, recursively, all constructors of datatypes mentioned in the top-level datatype, going all the way down) are visible. Thanks, Richard

1 0

[FYI] LLVM: function prefix data (a.k.a. tables-next-to-code) committed
by Gabor Greif 16 Sep '13

16 Sep '13

This looks pretty exiting for LLVM IR-generation: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130909/188042… GHC 7.10 might generate LLVM IR including embedded tables without resorting to linker tricks/postprocessing when targeting LLVM 3.4! The relevant LLVM bug is http://llvm.org/bugs/show_bug.cgi?id=14080 and GHC Trac: http://ghc.haskell.org/trac/ghc/ticket/4213 Cheers, Gabor

4 4

Today's validation failures
by Jan Stolarek 16 Sep '13

16 Sep '13

I'm getting these validation failures today on HEAD (64 bit Linux): OVERALL SUMMARY for test run started at Mon Sep 16 16:18:39 BST 2013 3793 total tests, which gave rise to 15020 test cases, of which 11569 were skipped 28 had missing libraries 3362 expected passes 58 expected failures 0 caused framework failures 1 unexpected passes 2 unexpected failures Unexpected passes: rts linker_unload (normal) Unexpected failures: perf/compiler T5837 [stat not good enough] (normal) rts T5435_v [bad stdout] (normal) T5837 started to fail randomly after the AMP warnings patch, but the two RTS failures are new. Edward, T5435_v is something you've been working on recently - could you take a look? Here is some output that might be helpful: =====> linker_unload(normal) 2475 of 3793 [0, 0, 0] cd ./rts && $MAKE -s --no-print-directory linker_unload </dev/null >linker_unload.run.stdout 2>linker_unload.run.stderr *** unexpected pass for linker_unload(normal) =====> T5435_v(normal) 2479 of 3793 [0, 0, 0] cd ./rts && $MAKE -s --no-print-directory T5435_v </dev/null >T5435_v.run.stdout 2>T5435_v.run.stderr Actual stdout output differs from expected: --- ./rts/T5435_v.stdout 2013-09-16 15:19:05.521987217 +0100 +++ ./rts/T5435_v.run.stdout 2013-09-16 16:25:21.902356951 +0100 @@ -1,2 +1 @@ -initializer run success *** unexpected failure for T5435_v(normal) Janek

2 1

7.8 Release Update
by Austin Seipp 16 Sep '13

16 Sep '13

Friends, After talking with SPJ, we've decided that the cutoff date for the 7.8 feature window will essentially start on Monday, the 16th. This is the beginning of the week before ICFP. This is a week from tomorrow. Afterwords, I suspect we will cut the 7.8 branch in early October (my notes tentatively say Oct. 9th.) This will give us a few weeks of straight bugfixing. Don't let this scare you too much. We're doing this at the beginning of the week so we have time to sort things out. Bug fixes will of course continuously be welcome until the 7.8 branch. However, for pending features, I'd like a status update. Everyone mentioned below, please reply to clarify anything: * Iavor Diatchki and SPJ are working together on the type-nats-simple branch. I believe this will hopefully land in time. Iavor, SPJ - can you comment here? * Trevor and Iavor are also working on kinds without data. Any word here? * Geoffrey is currently moving, but he says the SIMD work and new template-haskell work will land by the end of this week, which is great. * Patrick Palka has a few loose ends to tie off for the parallel compilation driver. I talked to him today, and after Andreas committed his bugfix to base, I believe everything is now working, with the deadlocks sorted out. Patrick, can you confirm? We can get this merged ASAP if so. * Pedro and Richard - what's the story on propositional equality, etc? This is mentioned on the status page[1] but I'm not sure what else needs to be done. I know Pedro committed the work to make manual Typeable instances an error, which is great. * Luite and Edsko will be talking about some final changes to the hooks patch, and afterwords it can hopefully be integrated. I'll keep up with them this week. * I am currently working on integrating the Applicative-Monad warning, but this requires some upstream patches for the build to work. However, we still need to sync several upstream libraries, and this will be happening over the next few weeks. Therefore, I may commit it, and incrementally fix validation errors as time goes on and me and Herbert sync upstreams. IMO, most of these look to be in good shape, I think. If you *do not think you'll make it by the 16th*, please let me know. We can possibly still land it the week of the 16th, provided I know ASAP. But we really really need to know, because many people will be gone the following week. In the following few days, I'm hoping going to finish off everything I can in the patch queue, and fix my remaining bugs, and investigate Dynamic GHCi in particular. Again, if you don't think you can make it on the 16th, but still within the week, we can of discuss it. -- Regards, Austin - PGP: 4096R/0x91384671

15 43

Re: HEADS UP: New primops on the way
by Jan Stolarek 16 Sep '13

16 Sep '13

(Sorry for double posting). New Alex and Happy will have conditional checks to see whether they are generating code for GHC <=7.6 or for GHC > 7.6. The only two intended situations when things will go wrong are: 1) You have these new versions of Alex and Happy and you are trying to compile 7.7 HEAD that does not contain new primops. Alex/Happy will generate calls to new primops, but since your HEAD doesn't have them the build will fail during stage2. 2) You have HEAD containing new primops, but you have old versions of Alex and Happy. This might happen if you upgrade Alex anmd Happy, pull changes but try to build without cleaning. Again, stage2 will fail because Alex/Happy will generate calls to old primops. ./configure will check whether an up-to-date versions of Alex and Happy are installed on the system. Note also that both Alex and Happy already have tons of such conditionals so there is nothing new going on in here: #if __GLASGOW_HASKELL__ >= 603 #include "ghcconfig.h" #elif defined(__GLASGOW_HASKELL__) #include "config.h" #endif #if __GLASGOW_HASKELL__ >= 503 import Data.Array import Data.Char (ord) import Data.Array.Base (unsafeAt) #else import Array import Char (ord) #endif #if __GLASGOW_HASKELL__ >= 503 import GHC.Exts #else import GlaExts #endif Janek ----- Oryginalna wiadomość ----- Od: "Joachim Breitner" <mail(a)joachim-breitner.de> Do: ghc-devs(a)haskell.org Wysłane: poniedziałek, 16 wrzesień 2013 15:04:44 Temat: Re: HEADS UP: New primops on the way Hi, Am Montag, den 16.09.2013, 15:48 +0200 schrieb Jan Stolarek: > 1) Upgrade to latest versions of Alex and Happy (cabal update && cabal > install alex happy). These versions are not yet available. When they > are DO NOT INSTALL THEM UNTIL CHANGES ARE PUSHED INTO HEAD. why? Will they not be backwards-compatible? Does this mean that I cannot have a system (without sandboxing) that can build both ghc-7.6 and ghc-7.8? I’m worried about the implications for distribution package maintainers, where ghc, happy and alex are independent packages. Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata(a)joachim-breitner.de _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

2 1

Re: HEADS UP: New primops on the way
by Jan Stolarek 16 Sep '13

16 Sep '13

----- Oryginalna wiadomość ----- Od: "Jan Stolarek" <jan.stolarek(a)p.lodz.pl> Do: "Joachim Breitner" <mail(a)joachim-breitner.de> Wysłane: poniedziałek, 16 wrzesień 2013 15:14:01 Temat: Re: HEADS UP: New primops on the way New Alex and Happy will have conditional checks to see whether they are generating code for GHC <=7.6 or for GHC > 7.6. The only two intended situations when things will go wrong are: 1) You have these new versions of Alex and Happy and you are trying to compile 7.7 HEAD that does not contain new primops. Alex/Happy will generate calls to new primops, but since your HEAD doesn't have them the build will fail during stage2. 2) You have HEAD containing new primops, but you have old versions of Alex and Happy. This might happen if you upgrade Alex anmd Happy, pull changes but try to build without cleaning. Again, stage2 will fail because Alex/Happy will generate calls to old primops. ./configure will check whether an up-to-date versions of Alex and Happy are installed on the system. Note also that both Alex and Happy already have tons of such conditionals so there is nothing new going on in here: #if __GLASGOW_HASKELL__ >= 603 #include "ghcconfig.h" #elif defined(__GLASGOW_HASKELL__) #include "config.h" #endif #if __GLASGOW_HASKELL__ >= 503 import Data.Array import Data.Char (ord) import Data.Array.Base (unsafeAt) #else import Array import Char (ord) #endif #if __GLASGOW_HASKELL__ >= 503 import GHC.Exts #else import GlaExts #endif Janek ----- Oryginalna wiadomość ----- Od: "Joachim Breitner" <mail(a)joachim-breitner.de> Do: ghc-devs(a)haskell.org Wysłane: poniedziałek, 16 wrzesień 2013 15:04:44 Temat: Re: HEADS UP: New primops on the way Hi, Am Montag, den 16.09.2013, 15:48 +0200 schrieb Jan Stolarek: > 1) Upgrade to latest versions of Alex and Happy (cabal update && cabal > install alex happy). These versions are not yet available. When they > are DO NOT INSTALL THEM UNTIL CHANGES ARE PUSHED INTO HEAD. why? Will they not be backwards-compatible? Does this mean that I cannot have a system (without sandboxing) that can build both ghc-7.6 and ghc-7.8? I’m worried about the implications for distribution package maintainers, where ghc, happy and alex are independent packages. Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata(a)joachim-breitner.de _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

HEADS UP: New primops on the way
by Jan Stolarek 16 Sep '13

16 Sep '13

There will be a major change in primops pushed into HEAD, hopefully with next 24 hours. This change breaks backwards compatibility for comparison primops and ONCE IT IS PUSHED will require you to: 1) Upgrade to latest versions of Alex and Happy (cabal update && cabal install alex happy). These versions are not yet available. When they are DO NOT INSTALL THEM UNTIL CHANGES ARE PUSHED INTO HEAD. 2) Blow away your build. Be sure to run ./configure to pick up new versions of Alex and Happy 3) Rebase your branches on top of HEAD, if these branches were in a repository affected by primop change. Repositories that will be affected: GHC, testsuite, array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, template-haskell. Janek

3 2

Trac #2110
by Simon Peyton-Jones 16 Sep '13

16 Sep '13

Joachim I'm not convinced about your solution. It seems a bit of a hack. Moreover, the very same issue arises for ordinary type classes, so I'd prefer to solve it for all of them at once. Finally, the very existence of Coercible is going to eliminate most of these (map Age) calls anyhow. Using them, and then a RULE to optimise them away, seems perverse. Do paste this email into the ticket... I'm on a plane. Suppose f :: (a->a->a) -> [a] -> [a], and fGr :: [a] -> [a] Now consider {-# RULE "foo" f (>) = fGr #-} which would translate to the following CoreRule: forall a, d:Ord a. f a ((>) a d) = fGr If we saw a call to f in a polymorphic context, the rule would fire g :: Ord a => [a] -> blah g xs = ...(f (>) xs).... But if we specialise g with a type signature, suddenly the rule wouldn't fire: g :: [Int] -> blah g xs = ...(f (>) xs).... Why? Because the (>) would simplify to grInt, which isn't what the RULE looks for. This is similar to your use of coerce simplifying too eagerly. The right solution seems to be to give the RULE a chance to fire before inlining/simplifying calls to (>). One way to do that is to prevent the ClassOp rule (defined in MkId) from firing in the "gentle" phase, which is always the first simplifier phase. I'm not sure of the consequences of that; see Note [RULEs enabled in SimplGently] in CoreMonad. Moreover currently BuiltinRules don't have an Activation to say when they should be active. This would be easy to change though.

1 0