RE: Pusing to haddock

| if you look in the 'packages' text-file at the top of GHC's source-tree, | you'll notice that haddock's upstream repo is declared as | ssh://g...@github.com/haskell/haddock.git | | And you should have permission to push there. Oh yes, thanks -- I'd forgotten that AGAIN. I have now pushed to

Re: Pusing to haddock

On 2016-06-13 at 23:44:14 +0200, Ben Gamari wrote: > Simon Peyton Jones writes: >> Devs, >> I want to push to the haddock repo, to fix the build. But I can’t. >> .git/modules/utils/haddock/ contains >> >> [remote "origin"] >> >>url = git://git.haskell.org/haddock.git

RE: Pusing to haddock

| Hmm, I suspect this means that you (or perhaps just this key?) don't | have push permission to the haskell.org Haddock repository. We should | rectify this. Herbert, could you verify this when you get a chance? I'm sure I used to be able to. I know I've done this before. | > What now? I attach

Re: Pusing to haddock

Simon Peyton Jones writes: > Devs, > I want to push to the haddock repo, to fix the build. But I can’t. > .git/modules/utils/haddock/ contains > > [remote "origin"] > >url = git://git.haskell.org/haddock.git > > pushurl = ssh://g...@git.haskell.org/haddock.git

Pusing to haddock

Devs, I want to push to the haddock repo, to fix the build. But I can’t. .git/modules/utils/haddock/ contains [remote "origin"] url = git://git.haskell.org/haddock.git pushurl = ssh://g...@git.haskell.org/haddock.git fetch = +refs/heads/*:refs/remotes/origin/* I’m on branch

Inferring instance constraints with DeriveAnyClass

Andres, I'm trying to think of a proper solution to Trac #12144 [1]. This bug triggers when you try to use DeriveAnyClass in a somewhat exotic fashion: {-# LANGUAGE DeriveAnyClass, KindSignatures #-} class C (a :: * -> *) data T a = MkT (a -> Int) deriving C This currently gives a

haddock

Ah! I forgot to push a one-line difff to haddock, which is breaking the build. Sorry. Gotta go right now but will do tonight. Meanwhile all should be ok if you swtich off Haddock Simon ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Force GC calls out of the straight line execution path

Hi Ömer, I just checked and I do not see this behavior in 8.0.1 native code, it is only seen in 7.10.3. So I guess this got fixed in 8.0. How about the llvm generated code? Can we control this behavior for llvm generated code as well? I first noticed this in llvm generated code with ghc-7.10.3.

Re: Force GC calls out of the straight line execution path

Hi Harendra, Would it be possible for you to provide a minimal example that compiles to such assembly? It's hard to tell if this is an easy case. Also, just to make sure, you're using -O, right? (I'm not sure if we have a related transformation enabled with -O but just to make sure...)

Force GC calls out of the straight line execution path

Hi, I noticed in the generated code (llvm as well as native) that in some cases the GC calls are in the straight path and the regular code is out of the straight line path. Like this: => 0x408fc0: lea0x30(%r12),%rax => 0x408fc5: cmp0x358(%r13),%rax => 0x408fcc: jbe0x408fe9

CoreToStg Asserts

Hi *, I'm hoping someone could help me understand what the asserts in CoreToStg on line 240 and 216 are trying to tell me. I hit both of them while trying to compile libraries as dyn. WARNING: file compiler\stgSyn\CoreToStg.hs, line 250 $trModule2 False True ghc-stage1.exe: panic! (the

Re: CMM-to-ASM: Register allocation wierdness

My earlier experiment was on GHC-7.10.3. I repeated this on GHC-8.0.1 and the assembly traced was exactly the same except for a marginal improvement. The 8.0.1 code generator removed the r14/r11 swap but the rest of the register ring shift remains the same. I have updated the github gist with the