- ghc-devs - Haskell.org

Reverted f723ba2f3b6d778f903fb1de4a5af93fe65eed10
by Ben Gamari 13 Dec '16

13 Dec '16

Hi Simon, Earlier today I noticed that the testsuite started failing with f723ba2f3b6d778f903fb1de4a5af93fe65eed10 due to break024 and break011. See https://phabricator.haskell.org/harbormaster/build/16407/ (I've included the output differences below). I've reverted the patch to keep the tree buildable but obviously feel free to commit again when it validates. Cheers, - Ben --- "/tmp/ghctest-zc_e5ng4/test spaces/./ghci.debugger/scripts/break011.run/break011.stdout.normalised" 2016-12-13 01:09:56.868988119 +0000 +++ "/tmp/ghctest-zc_e5ng4/test spaces/./ghci.debugger/scripts/break011.run/break011.run.stdout.normalised" 2016-12-13 01:09:56.868988119 +0000 @@ -40,17 +40,9 @@ CallStack (from HasCallStack): error, called at Test7.hs:<line>:<column> in <package-id>:Main Stopped in <exception thrown>, <unknown> -_exception :: e = SomeException - (ErrorCallWithLocation - "foo" - "CallStack (from HasCallStack): - error, called at Test7.hs:<line>:<column> in <package-id>:Main") +_exception :: e = _ Stopped in <exception thrown>, <unknown> -_exception :: e = SomeException - (ErrorCallWithLocation - "foo" - "CallStack (from HasCallStack): - error, called at Test7.hs:<line>:<column> in <package-id>:Main") +_exception :: e = _ *** Exception: foo CallStack (from HasCallStack): error, called at Test7.hs:<line>:<column> in <package-id>:Main --- "/tmp/ghctest-zc_e5ng4/test spaces/./ghci.debugger/scripts/break024.run/break024.stdout.normalised" 2016-12-13 01:09:57.464988119 +0000 +++ "/tmp/ghctest-zc_e5ng4/test spaces/./ghci.debugger/scripts/break024.run/break024.run.stdout.normalised" 2016-12-13 01:09:57.464988119 +0000 @@ -11,8 +11,7 @@ (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError [] "error" Nothing Nothing) Stopped in <exception thrown>, <unknown> -_exception :: e = SomeException - (GHC.IO.Exception.IOError Nothing GHC.IO.Exception.UserError ....) +_exception :: e = _ Stopped in <exception thrown>, <unknown> _exception :: e = _ _exception = SomeException

2 1

Reason for fixing minimum bootstrap version at 2 major releases ago?
by Shea Levy 13 Dec '16

13 Dec '16

Hi all, I'm wondering, why do we require ghc to be bootstrappable with the past 2 major releases instead of just the past 1? Is it a common case that someone is compiling GHC but can't easily get the latest release? Thanks, Shea

2 1

Re: [GHC] #876: Length is not a good consumer
by George Colpitts 13 Dec '16

13 Dec '16

my apologies, sorry for the terrible bug report On Sun, Dec 11, 2016 at 11:05 AM GHC <ghc-devs(a)haskell.org> wrote: > #876: Length is not a good consumer > -------------------------------------+------------------------------------- > Reporter: ariep@… | Owner: > Type: bug | Status: new > Priority: lowest | Milestone: 7.6.2 > Component: libraries/base | Version: 6.5 > Resolution: | Keywords: length > Operating System: Linux | Architecture: > | Unknown/Multiple > Type of failure: Runtime | Test Case: > performance bug | perf/should_run/T876 > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by nomeata): > > This code, compiled with `-O, does fuse, and allocates nothing (or > constant amounts) > {{{#!hs > > module Foo where > x :: Int -> Int > x n = length [0..(10^n)::Int] > }}} > > {{{ > $ ghci -fobject-code -O Foo > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) > Ok, modules loaded: Foo. > Prelude Foo> :set +s > Prelude Foo> x 1 > 11 > (0.03 secs, 14,976,744 bytes) > Prelude Foo> x 7 > 10000001 > (0.02 secs, 0 bytes) > Prelude Foo> x 8 > 100000001 > (0.04 secs, 0 bytes) > }}} > > (almost) HEAD: > {{{ > GHCi, version 8.1.20161117: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Foo (.hs -> .o) > WARNING: file compiler/simplCore/SimplCore.hs, line 663 > Simplifier bailing out after 4 iterations [58, 14, 2, 2] > Size = {terms: 96, types: 32, coercions: 0} > Ok, modules loaded: Foo (Foo.o). > Prelude Foo> :set +s > Prelude Foo> x 1 > 11 > (0.19 secs, 94,792 bytes) > Prelude Foo> x 2 > 101 > (0.01 secs, 94,648 bytes) > Prelude Foo> x 7 > 10000001 > (0.01 secs, 98,568 bytes) > Prelude Foo> x 8 > 100000001 > (0.05 secs, 98,448 bytes) > }}} > > Testing this in with interpreted code is not sufficient, as the optimizer > does less in that case. So so far, everything seems as expected to me. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/876#comment:30> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

2 3

Please don’t break travis
by Joachim Breitner 12 Dec '16

12 Dec '16

Hi, again, Travis is failing to build master since a while. Unfortunately, only the author of commits get mailed by Travis, so I did not notice it so far. But usually, when Travis reports a build failure, this is something actionable! If in doubt, contact me. The breakage at the moment occurs only with -DDEBUG on: Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161118 for x86_64-unknown-linux): No match in record selector is_iloc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for rn017(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161118 for x86_64-unknown-linux): No match in record selector is_iloc Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T7672(normal) And started appearing, unless I am mistaken, with From: Matthew Pickering < matthewtpickering(a)gmail.com > Date: Fri, 18 Nov 2016 16:28:30 +0000 Subject: [PATCH] Optimise whole module exports We directly build up the correct AvailInfos rather than generating lots of singleton instances and combining them with expensive calls to unionLists. There are two other small changes. * Pushed the nubAvails call into the explicit export list branch as we construct them correctly and uniquely ourselves. * fix_faminst only needs to check the first element of the export list as we maintain the (yucky) invariant that the parent is the first thing in it. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie, niteria Differential Revision: https://phabricator.haskell.org/D2657 Matthew, can you verify that this is a regression introduce here? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

5 7

RE: More windows woe
by Simon Peyton Jones 10 Dec '16

10 Dec '16

Reverting didn’t work Appluying D2817 didn’t work: /c/code/HEAD$ c:/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161209: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `base-4.9.0.0' ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown symbol `_unlock_file' Now it’s ‘unlock_file’. I’ll try adding that. Simon From: Phyx [mailto:lonetiger@gmail.com] Sent: 09 December 2016 23:07 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: More windows woe When fixing bootstrapping with pre 7.10.3 compilers this accidentally broke. There's a patch up to fix it https://phabricator.haskell.org/D2817 If you're on 7.10.3 or later for your bootstrapping compiler revert 6da62535469149d69ec98674db1c51dbde0efab1 and it should work again. Just waiting for a buildbot build to commit the above patch. On Fri, Dec 9, 2016 at 10:44 PM, Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> wrote: I see that anything involving ghci fails: /c/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161209: http://www.haskell.org/ghc/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell…> :? for help ghc-stage2.exe: unable to load package `base-4.9.0.0' ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown symbol `_lock_file' ghc-stage2.exe: Could not on-demand load symbol '__mingw_vfprintf' ghc-stage2.exe: C:\code\HEAD\libraries\base\dist-install\build\HSbase-4.9.0.0.o: unknown symbol `__mingw_vfprintf' It’s frustrating. It used to work! Simon _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…>

1 1

More windows woe
by Simon Peyton Jones 10 Dec '16

10 Dec '16

I see that anything involving ghci fails: /c/code/HEAD/inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161209: http://www.haskell.org/ghc/ :? for help ghc-stage2.exe: unable to load package `base-4.9.0.0' ghc-stage2.exe: C:\code\HEAD\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a: unknown symbol `_lock_file' ghc-stage2.exe: Could not on-demand load symbol '__mingw_vfprintf' ghc-stage2.exe: C:\code\HEAD\libraries\base\dist-install\build\HSbase-4.9.0.0.o: unknown symbol `__mingw_vfprintf' It's frustrating. It used to work! Simon

2 4

Attempt at a real world benchmark
by Joachim Breitner 10 Dec '16

10 Dec '16

Hi, I have talked so much about it, it was about time to actually follow through. I took a real-world program (tttool, one of mine, show shameless), inlined all the dependencies so that it would compile without Cabal, just with a single invocation of GHC on the 277 modules. The state, including a README, can be found at https://github.com/nomeata/tttool-nofib#turning-tttool-into-a-benchmark I am not sure how useful this is going to be: + Tests lots of common and important real-world libraries. − Takes a lot of time to compile, includes CPP macros and C code. (More details in the README linked above). It is late, so I’ll just send this out as it is for now to get the discussion going if this is a useful approach, or what should be done different. (If this is deemed to be useful, I’d do the same for, say, pandoc next). Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

15 25

Windows build again
by Simon Peyton Jones 10 Dec '16

10 Dec '16

Windows build is broken in a new way. When I run validate I end up with sh.exe processes that consume a full CPU forever. See the process log below. Note that these are not GHC processes: they are shells! I have no conception of what they are doing. Any ideas, or things I can to do gather more evidence? This is an up to date HEAD, with some small changes to GHC. I suppose I can try a completely clean HEAD, but I can't see how my changes could make the shell loop. Simon [cid:image003.jpg@01D2526B.A8994140]

2 1

Differential builds with on Darwin now enabled
by Ben Gamari 09 Dec '16

09 Dec '16

Hello everyone, Note that the Mac Mini builder will now build submitted Differentials as well as commits to master. Originally I was hesitant to take this step since unreviewed differentials are essentially untrusted code; however it has become clear that to keep regressions from entering the tree we will need to be a bit more proactive in testing code before it is committed. Hopefully this helps! Lastly, I'd like to take this opportunity to once again thank Futurice for providing this hardware to us. We all owe them a debt of gratitude. Cheers, - Ben

1 0

GHC 8.2 status
by Ben Gamari 09 Dec '16

09 Dec '16

Hello everyone, While we are still trying to get 8.0.2 out the door, 8.2.1 is quickly approaching. If you have a feature that you would like to see in 8.2, please add it to the 8.2 status page [1] as soon as possible and let us know; we would like to cut the ghc-8.2 branch in late December for a release in February so the hour is growing late. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1

2 1