Re: GHC on mingw-w64 / gcc 4.8.3 on Windows

Ah, Gintautas! Since I don't follow Phabricator I didn't even suspect you are making all this work. I had a patch to migrate to mingw-w64 gcc 4.8.x (and even 4.9.x, which requires extra runtime linker support) both for 64-bit and 32-bit for more than half of the year already. That patch is

Re: Call Arity, oneShot, or both

Joachim Breitner כתב That would be great! But do we have evidence of this user-written code that benefits? So far I have only seen relevant improvement due to list-fusion a left-foldish function. I was under the impression that the transformation was much more general than that, improving

Re: Proposal: Improving the LLVM backend by packaging it

On Fri, 24 Oct 2014 18:52:53 -0500 Austin Seipp aus...@well-typed.com wrote: I won't repeat what's on the wiki page too much, but the TL;DR version is: we should start packaging a version of LLVM, and shipping it with e.g. binary distributions of GHC. It's just a lot better for everyone. I

Re: Call Arity, oneShot, or both

Hi, Am Montag, den 27.10.2014, 03:39 -0400 schrieb David Feuer: Joachim Breitner כתב That would be great! But do we have evidence of this user-written code that benefits? So far I have only seen relevant improvement due to list-fusion a

Re: GHC on mingw-w64 / gcc 4.8.3 on Windows

Since I don't follow Phabricator I didn't even suspect you are making all this work. Yes, looks like I undercommunicated, sorry about that. I started off with the patch to download the tarballs and just went ahead for standartising of mingw-w64 without quite realising how involved that would

Re: GHC on mingw-w64 / gcc 4.8.3 on Windows

Hello *, On 2014-10-27 at 11:37:01 +0100, Gintautas Miliauskas wrote: Since I don't follow Phabricator I didn't even suspect you are making all this work. Yes, looks like I undercommunicated, sorry about that. In the hopes to aid with communication, I've just created a GHC Windows Task Force

Re: Windows build broken in Linker.c

FYI, after the fix ghc builds again on Windows 32-bit, but validate.sh fails: rts\Linker.c: In function 'allocateImageAndTrampolines': rts\Linker.c:3657:31: error: unused parameter 'member_name' [-Werror=unused-parameter] pathchar* arch_name, char* member_name,

Re: GHC on mingw-w64 / gcc 4.8.3 on Windows

-7.9.20140917. I had no problems with that build. I've made only the minor modification today (20141027) to let it apply to today's HEAD cleanly. The last 32-bit build was made 4-6 month ago perhaps. I have no much time to test this patch agaings today's HEAD, so I would greatly appreciate

RE: [commit: ghc] wip/oneShot: Avoid inlining oneShot in unfoldings (16066a1)

Sorry -- I missed the fact that it wasn't on HEAD! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Joachim | Breitner | Sent: 26 October 2014 23:52 | To: ghc-devs@haskell.org | Subject: Re: [commit: ghc] wip/oneShot: Avoid inlining oneShot

RE: Call Arity, oneShot or both

| The biggest loser is calendar, which uses scanl. I am not fully sure | what went wrong here: Either the one-shot annotation on the lambda’s | variable got lost somewhere in the pipeline, or despite it being there, | the normal arity analysis did not use it. | | But there is also a winner, fft2,

Re: [commit: ghc] master: Implementation of hsig (module signatures), per #9252 (aa47995)

Thanks for the note; I'm validating a patch that fixes this. Landing soon! Edward Excerpts from Joachim Breitner's message of 2014-10-25 02:14:53 -0700: Hi Edwardd, Am Freitag, den 24.10.2014, 23:47 + schrieb g...@git.haskell.org: