- ghc-devs - Haskell.org

Re: [Reminder] Merge window for 8.10 closing
by Ryan Scott 16 Oct '19

16 Oct '19

I've been working on a fix for #13154 [1] that I'd like to get into GHC 8.10. My patch [2] is mostly done; I just need to find the time to add comments and perform some slight code cleanup. (Hopefully this week!) Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/issues/13154 [2] https://gitlab.haskell.org/RyanGlScott/ghc/tree/wip/T13154-take-two

1 0

[Reminder] Merge window for 8.10 closing
by Ben Gamari 16 Oct '19

16 Oct '19

Hello everyone, As described on the GHC status page [1] the freeze for GHC 8.10 is coming up shortly. If you have work that you would like to get into 8.10 and haven't yet opened an MR you should either do so today or be in touch with me. After this freeze begins there will be approximately a week of reduced merge rate to let the master branch settle before the branch, which could happen as early as early next week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/milestones/54?title=8.10.1

2 1

Help with debugging a batch mode (or type checker) bug
by Ömer Sinan Ağacan 15 Oct '19

15 Oct '19

Hi, In !1304 I'm currently having a bug where I get correct IdInfos for imported Ids in one-shot mode (-c), but not when I use batch mode (--make). If I add a few prints I can see that in hscIncrementalCompile right before hscIncrementalFrontend the hsc_HPT has the correct IdInfos for the imported Ids, but somehow in the desugarer output the IdInfo is lost. Can anyone point me to the right places in the typechecker or the desugarer for me to look at? Thanks, Ömer

2 4

Switch/Case optimisations
by chessai . 14 Oct '19

14 Oct '19

I thought Andreas Klebinger in particular might find this interesting. The talk is here: https://youtu.be/IAdLwUXRUvg?t=1867 (timestamp is 31:07) basically, if you have an interpreter consisting of a switch statement inside an infinite loop, there's a mechanical transformation using GOTOs that causes a 15% speedup in the switch statement blob, there's n + 1 basic blocks, each of which has a jmp back to the first basic block with probability 1, and the first basic block has a jmp that will go to one of the other n basic blocks with probability 1 / n whereas in the goto statement setup, there's n basic blocks, each of which has a jmp that will go to one of the other n - 1 basic blocks with probability 1 / (n - 1) so if your sequence of instructions is produced by a markov decision process, then the branch predictor will efficiently predict in the latter situation but not necessarily the former in the goto setup the callgraph looks like a complete graph on n vertices whereas in the switch setup it looks like a bipartite graph on (1, n) vertices (where the edges represent both "is called by" and "calls") and because of all those extra edges (n^2 rather than 2n) there's more spots for the branch predictor to build up data At 39:13 he explains that you get per-address jmp predictions. If you only share a single relative jmp, the cpu only knows how common every opcode is. But, if you have a jmp from each opcode, to the next, the cpu can determine how common an opcode A is followed an opcode B. He references godbolt (https://godbolt.org/) which seems like a useful tool. and mentions that ruby, jvm (on android only?), and some arm compilers implement this. There are some tradeoffs - code size does increase. According to a GCC developer in the audience, GCC is not currently able to do this. I have no idea about Clang. Thanks

1 0

validate-x86_64-darwin failing
by Richard Eisenberg 14 Oct '19

14 Oct '19

Hi devs, validate-x86_64-darwin seems to be failing. I've restarted it when I came across the failure, but several small patches last night tripped on this. Richard

4 6

CI fails in git submodule update --init --recursive for 386-linux-deb9
by Roland Senn 13 Oct '19

13 Oct '19

Hi After pushing some commits, while running a CI pipeline, I persistently get the following error for the validate-i386-linux-deb9 step: $ git submodule update --init --recursive fatal: Unable to create '/builds/RolandSenn/ghc/.git/modules/libraries/Cabal/index.lock': File exists. Another git process seems to be running in this repository, e.g. an editor opened by 'git commit'. Please make sure all processes are terminated then try again. If it still fails, a git process may have crashed in this repository earlier: remove the file manually to continue. Unable to checkout '63331c95ed15cc7e3d83850d308dc3a86a8c3c76' in submodule path 'libraries/Cabal' See https://gitlab.haskell.org/RolandSenn/ghc/pipelines/11311 . How can I fix this? I have no access to this 386 linux machine, so I'm unable to delete the file. Roland

1 0

ByteArray# as a foreign import argument?
by Shao, Cheng 11 Oct '19

11 Oct '19

Hello devs, I've been trying to figure out how to pass lifted types as foreign types, then encountered the following code in the `DsCCall` module (https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/deSugar/DsCCall.hs#…) ``` -- Byte-arrays, both mutable and otherwise; hack warning -- We're looking for values of type ByteArray, MutableByteArray -- data ByteArray ix = ByteArray ix ix ByteArray# -- data MutableByteArray s ix = MutableByteArray ix ix (MutableByteArray# s) | is_product_type && data_con_arity == 3 && isJust maybe_arg3_tycon && (arg3_tycon == byteArrayPrimTyCon || arg3_tycon == mutableByteArrayPrimTyCon) = do case_bndr <- newSysLocalDs arg_ty vars@[_l_var, _r_var, arr_cts_var] <- newSysLocalsDs data_con_arg_tys return (Var arr_cts_var, \ body -> Case arg case_bndr (exprType body) [(DataAlt data_con,vars,body)] ) ``` It seems we allow a "ByteArray" type as a foreign import argument, if the third field of the datacon is a ByteArray# or MutableByteArray#. But I can't find such a ByteArray type definition in today's common packages. What's the rationale for this piece of code? Cheers, Cheng

4 8

GHC_STAGE
by Shayne Fletcher 10 Oct '19

10 Oct '19

Hi Ben, I observed warnings of this kind in a couple of places building head yesterday: ``` compiler/utils/FastString.hs:336:5: error: warning: 'GHC_STAGE' is not defined, evaluates to 0 [-Wundef] | 336 | #if GHC_STAGE < 2 | ^ #if GHC_STAGE < 2 ^ ``` ``` compiler/main/DynFlags.hs:323:5: error: warning: 'GHC_STAGE' is not defined, evaluates to 0 [-Wundef] | 323 | #if GHC_STAGE >= 2 | ^ #if GHC_STAGE >= 2 ^ ``` I was using the `hadrian/build.stack.sh` approach. Figured you'd want to know! -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* <https://digitalasset.com/>, creators of *DAML <https://daml.com/>* -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

2 2

Unsquashed merge requests
by Andreas Klebinger 10 Oct '19

10 Oct '19

Hello devs, I've recently seen a few MR's make it into master with commits which rather obviously were meant to be squashed. Please look out for this when assigning MRs to marge. Cheers Andreas

1 0

T13615 fragile?
by Richard Eisenberg 09 Oct '19

09 Oct '19

Hi devs, https://gitlab.haskell.org/rae/ghc/-/jobs/173504 <https://gitlab.haskell.org/rae/ghc/-/jobs/173504> tells me that T13615 failed -- but only in DEBUG mode. My patch is nowhere near this code. Is this a new fragile test? The number of fragile tests seems to be growing quickly. And once a test is labeled fragile, we're essentially no longer tracking the test, if I understand correctly. So that's a bit unfortunate. Thanks, Richard

3 2