- ghc-devs - Haskell.org

T3064 failures
by David Feuer 17 Oct '14

17 Oct '14

I don't know what's going on, but T3064 is giving some substantial performance trouble, making all the validations fail: max_bytes_used value is too high: Expected T3064(normal) max_bytes_used: 13251728 +/-20% Lower bound T3064(normal) max_bytes_used: 10601382 Upper bound T3064(normal) max_bytes_used: 15902074 Actual T3064(normal) max_bytes_used: 17472560 Deviation T3064(normal) max_bytes_used: 31.9 % bytes allocated value is too high: Expected T3064(normal) bytes allocated: 385145080 +/-5% Lower bound T3064(normal) bytes allocated: 365887826 Upper bound T3064(normal) bytes allocated: 404402334 Actual T3064(normal) bytes allocated: 1372924224 Deviation T3064(normal) bytes allocated: 256.5 % I don't know what's allocating an extra gigabyte, but unless there's a good reason, someone probably needs to tighten something up.

3 2

Merging a branch
by Simon Peyton Jones 16 Oct '14

16 Oct '14

Friends I have a branch, wip/new-flatten-skolems-Aug14, which has a long succession of work-in progress patches. Plus a couple of merges from HEAD. I'd like to completely re-organise the patches before committing to HEAD. How do I do that? Some kind of rebase? Clearly I want to start from current HEAD, rather than having weird merge patches involved. I was thinking of starting a new branch and doing a manual diff/patch, but that seems crude. I think that one other person (Iavor) has pulled from this branch, but he has not modified it. Thanks Simon

6 5

RTS validate failures on Linux
by Jan Stolarek 16 Oct '14

16 Oct '14

Simon, I'm getting this error when validating HEAD on 64 bit Linux: =================== "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Werror -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissi ng-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnest ed-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist -ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fom it-frame-pointer -optc-DRtsWay=\"rts_thr\" -static -optc-DTHREADED_RTS -H32m -O -Werror -Wall -H64m -O0 -Iincludes -Iincludes/dist -Iin cludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/posix/OSThreads.c -o rts/dist/build/posix/OSThreads.thr_o cc1: warnings being treated as errors rts/posix/OSThreads.c: In function ‘createOSThread’: rts/posix/OSThreads.c:132:40: error: unused parameter ‘name’ gmake[1]: *** [rts/dist/build/posix/OSThreads.thr_o] Error 1 =================== I believe this might be a result of your commit 674c631ea111233daa929ef63500d75ba0db8858 from Friday. Janek

2 1

RFC: Source-markup language for GHC User's Guide
by Herbert Valerio Riedel 15 Oct '14

15 Oct '14

Hello GHC Developers & GHC User's Guide writers, I assume it is common knowledge to everyone here, that the GHC User's Guide is written in Docbook XML markup. However, it's a bit tedious to write Docbook-XML by hand, and the XML markup is not as lightweight as modern state-of-the-art markup languages designed for being edited in a simple text-editor are. Therefore I'd like to hear your opinion on migrating away from the current Docbook XML markup to some other similarly expressive but yet more lightweight markup documentation system such as Asciidoc[1] or ReST/Sphinx[2]. There's obviously some cost involved upfront for a (semi-automatic) conversion[3]. So one important question is obviously whether the long-term benefits outweight the cost/investment that we'd incur for the initial conversion. All suggestions/comments/worries welcome; please commence brainstorming :) [1]: http://www.methods.co.nz/asciidoc/ [2]: http://sphinx-doc.org/ [3]: There's automatic conversion tools to aid (though manual cleanup is still needed) the initial conversion, such as https://github.com/oreillymedia/docbook2asciidoc As an example, here's the conversion of http://git.haskell.org/ghc.git/blob/HEAD:/docs/users_guide/extending_ghc.xml to Asciidoc: https://phabricator.haskell.org/P24 to give an idea how XML compares to Asciidoc

9 12

I'm going to disable DPH until someone starts maintaining it
by Austin Seipp 15 Oct '14

15 Oct '14

Everyone, I'm still working on the AMP, and of course, things aren't going as planned. Why is that? I'm attempting to update `vector` to the latest version from GitHub, as it has some fixes we need for AMP. Mostly, it has some instances we need. Unfortunately, this is basically impossible because dph is locked into a vector fork of ours that we have been maintaining for *months*, and doesn't work with the latest vector upstream (0.11) due to changes in the stream representation. This means I can either: 1) Fix everything in DPH to work with vector 0.11, which is probably going to take a lot of work. 2) Merely fix our fork of vector and let things continue working. This is much easier than #1. Now, you might say that #2 is clearly a preferable solution, and it's very easy - so just do that, Austin! But I don't want to do it. You could say this is the straw that has broken the camel's back. Why? Because I'm afraid I just don't have any more patience for DPH, I'm tired of fixing it, and it takes up a lot of extra time to build, and time to maintain. In fact I'm the only person who's committed to it in *months*, and that has only been to fix breakage. The hackage packages are out of date and sync with what's in the repository (I can't upload them, nor can anyone else besides Ben I believe). So - why are we still building it, exactly? We had a conversation about this months ago. The concern was that things would break and we don't want it to fall out of sync. We're at that point right now - things are breaking, it's out of sync, and it's a pain to keep fixing it, and the actual *benefits* we get from doing so are completely unclear to me. It basically just seems like extra work for nothing, honestly. Unless someone speaks[1] up *very* soon, I'm going to disable DPH during ./validate and the regular build. It will be possible to build it with a '--dph' flag (the dual of the current '--no-dph' flag), although it will be broken very soon with these incoming changes. Providing someone starts fixing it, I'm completely, 100% open to re-enabling it in ./validate by default. But I'm personally tired of fixing it. I'm CC'ing Manuel, Geoff & Ben for their inputs. [1] And by 'speak up', I mean I'd like to see someone actively step forward address my concerns above in a decisive manner. With patches. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 9

optimizing StgPtr allocate (Capability *cap, W_ n)
by Bulat Ziganshin 14 Oct '14

14 Oct '14

Hello, i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rt… if i correctly understand, it's speed-critical routine? i think that it may be improved in this way: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); /// here starts new improved code: bd = cap->r.rCurrentAlloc; if (bd == NULL || bd->free + n > bd->end) { if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) { .... } if (bd->free + n <= bd->start + BLOCK_SIZE_W) bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD) goto usual_alloc; } .... } /// and here it stops usual_alloc: p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } i think it's obvious - we consolidate two if's on the crirical path into the single one plus avoid one ADD by keeping highly-useful bd->end pointer further improvements may include removing bd==NULL check by initializing bd->free=bd->end=NULL and moving entire "if" body into separate slow_allocate() procedure marked "noinline" with allocate() probably marked as forceinline: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); bd = cap->r.rCurrentAlloc; if (bd->free + n > bd->end) return slow_allocate(cap,n); p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } this change will greatly simplify optimizer's work. according to my experience current C++ compilers are weak on optimizing large functions with complex execution paths and such transformations really improve the generated code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

FW: optimizing StgPtr allocate (Capability *cap, W_ n)
by Simon Peyton Jones 14 Oct '14

14 Oct '14

Simon, did you see this? Simon -----Original Message----- From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Bulat Ziganshin Sent: 14 October 2014 18:09 To: glasgow-haskell-users(a)haskell.org Subject: optimizing StgPtr allocate (Capability *cap, W_ n) Hello Glasgow-haskell-users, i'm looking a the https://github.com/ghc/ghc/blob/23bb90460d7c963ee617d250fa0a33c6ac7bbc53/rt… if i correctly understand, it's speed-critical routine? i think that it may be improved in this way: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); /// here starts new improved code: bd = cap->r.rCurrentAlloc; if (bd == NULL || bd->free + n > bd->end) { if (n >= LARGE_OBJECT_THRESHOLD/sizeof(W_)) { .... } if (bd->free + n <= bd->start + BLOCK_SIZE_W) bd->end = min (bd->start + BLOCK_SIZE_W, bd->free + LARGE_OBJECT_THRESHOLD) goto usual_alloc; } .... } /// and here it stops usual_alloc: p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } i think it's obvious - we consolidate two if's on the crirical path into the single one plus avoid one ADD by keeping highly-useful bd->end pointer further improvements may include removing bd==NULL check by initializing bd->free=bd->end=NULL and moving entire "if" body into separate slow_allocate() procedure marked "noinline" with allocate() probably marked as forceinline: StgPtr allocate (Capability *cap, W_ n) { bdescr *bd; StgPtr p; TICK_ALLOC_HEAP_NOCTR(WDS(n)); CCS_ALLOC(cap->r.rCCCS,n); bd = cap->r.rCurrentAlloc; if (bd->free + n > bd->end) return slow_allocate(cap,n); p = bd->free; bd->free += n; IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); return p; } this change will greatly simplify optimizer's work. according to my experience current C++ compilers are weak on optimizing large functions with complex execution paths and such transformations really improve the generated code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Broken build: 32-bit FreeBSD, SmartOS, Solaris
by Páli Gábor János 14 Oct '14

14 Oct '14

Hello there, Looks one of the recent commits broke the x86 builds on multiple platforms [1][2][3]. The common error message basically is as follows: rts/Linker.c: In function 'mkOc': rts/Linker.c:2372:6: error: 'ObjectCode' has no member named 'symbol_extras' Please fix it! Note that the x86_64 counterparts of the affected builders completed their builds fine -- except for Solaris, but that has been broken already for a long time (relatively). [1] http://haskell.inf.elte.hu/builders/smartos-x86-head/144/10.html [2] http://haskell.inf.elte.hu/builders/freebsd-i386-head/403/10.html [3] http://haskell.inf.elte.hu/builders/solaris-x86-head/191/10.html

6 10

Building ghc on Windows with msys2
by Gintautas Miliauskas 13 Oct '14

13 Oct '14

Hello, I have been messing around a little bit with building GHC from source on Windows, and found the msys2 wikipage <https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2> quite useful, but somewhat outdated. Quite a few steps in those instructions are no longer necessary and can be omitted. I am working on cleaning up that wikipage right now and should be done in a day or two. I've found a recent email <http://www.haskell.org/pipermail/ghc-devs/2014-September/006251.html> in the middle of updating the wikipage about other people planning to do the same, so I thought I'd shoot an email to make sure that work is not being duplicated. msys2 seems to be in good shape and should probably be promoted to the primary suggested method to build ghc on Windows. Let's look into that once the new build instructions have been proofread and verified. Best regards, -- Gintautas Miliauskas

11 35

Errors building GHC on iOS with LLVM >= 3.4
by Murray Campbell 13 Oct '14

13 Oct '14

Hi, I am trying to help solve #9125 in which an ARM build creates binaries that mangle Float values. After a great deal of help from rwbarton (detailed in the comments) it would appear that the problem is actually in LLVM 3.0. (v3.0 is virtually insisted upon in the iOS build instructions) Building GHC 7.8.3 for the iOS simulator with LLVM 3.4 produces a compiler that creates well behaved binaries. Unfortunately, building the device version fails with several warnings along the lines of: /var/folders/02/0mv6cz6505x2xhzlr279k2340000gp/T/ghc5244_0/ghc5244_6-armv7s.s:2944:2: warning: deprecated since v7, use 'dmb' mcr p15, #0, r7, c7, c10, #5 and: libraries/ghc-prim/cbits/popcnt.c:76:38: warning: shift count >= width of type [-Wshift-count-overflow] popcount_tab[(unsigned char)(x >> 32)] + ^ ~~ before bailing with /var/folders/02/0mv6cz6505x2xhzlr279k2340000gp/T/ghc6860_0/ghc6860_6-armv7.s:3916:2: error: out of range pc-relative fixup value vldr d8, LCPI70_0 ^ /var/folders/02/0mv6cz6505x2xhzlr279k2340000gp/T/ghc6860_0/ghc6860_6-armv7s.s:3916:2: error: out of range pc-relative fixup value vldr d8, LCPI70_0 ^ Next I tried to build HEAD (plus phabricator D208) with LLVM 3.4 but got the same error. Various adventures with LLVM 3.5 ended with the same error. I am trying to educate myself in ARM assembly but in the meantime does this ring any bells for anyone? I don't see anything on the trac. Thanks, Murray Campbell

2 3