- ghc-devs - Haskell.org

Weight field in issues too fine grained?
by Ömer Sinan Ağacan 02 Jul '19

02 Jul '19

Hi, One of the problems I'm having when triaging is that I think the "weight" field for issues is currently too fine grained. The triage protocol[1] gives some idea but it's still up to the person who's doing triaging to decide, for example, between 7 vs. 10 for a runtime crash. I think a better "weight" field would be what we had in trac: highest, high, normal etc. that way we don't have to decide whether a runtime panic is 8 or 9 or 10, we'd just mark it as "highest". Now if we had a lot of issues with weight 8, 9, 10 etc. perhaps we'd use the weight field to prioritize, but in my experience we usually have very little such issues and they all get fixed before the next release, so the distinction between e.g. 8 vs. 9 is not useful or meaningful. Is it possible to do switch to trac-style priority/weight field in Gitlab? Anyone else think that this would be good? Ömer [1]: https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues#triage-protocol

5 10

What to do if your hadrian build starts failing (supportedLlvmVersion)
by Matthew Pickering 02 Jul '19

02 Jul '19

If you see this message: Exit code: 1 Stderr: compiler/llvmGen/LlvmCodeGen/Base.hs:192:36: error: • Couldn't match expected type ‘Int’ with actual type ‘(Integer, Integer)’ • In the first argument of ‘LlvmVersion’, namely ‘(7, 0)’ In the expression: LlvmVersion (7, 0) In an equation for ‘supportedLlvmVersion’: supportedLlvmVersion = LlvmVersion (7, 0) | 192 | supportedLlvmVersion = LlvmVersion sUPPORTED_LLVM_VERSION | ^^^^^ ) Then you need to delete the `includes/ghcautoconf.h` file. It is a file generated by the Make build system. Cheers, Matt

1 0

Workflow question (changing codegen)
by Ömer Sinan Ağacan 01 Jul '19

01 Jul '19

Hi all, I'm currently going through this torturous process and I'm hoping that someone here will be able to help. I'm making changes in the codegen. My changes are currently buggy, and I need a working stage 1 compiler to be able to debug. Basically I need to build libraries using the branch my changes are based on, then build stage 1 with my branch, so that I'll be able to build and run programs using stage 1 that uses my codegen changes. The changes are compatible with the old codegen (i.e. no changes in calling conventions or anything like that) so this should work. Normally I do this $ git checkout master $ git distclean && ./boot && ./configure && make $ git checkout my_branch $ cd compiler; make 1 This gives me stage 1 compiler that uses my buggy codegen changes, plus libraries built with the old and correct codegen. However the problem is I'm also adding a new file in my_branch, and the build system just doesn't register that fact, even after adding the line I added to compiler/ghc.cabal.in to compiler/ghc.cabal. So far the only way to fix this that I could find was to run ./configure again, then run make for a few seconds at the top level, then do `make 1` in compiler/. Unfortunately even that doesn't work when the master branch and my_branch have different dates, because `make` in master branch produces a different version than the `make` in my_branch, so the interface files become incompatible. Anyone have any ideas on how to proceed here? Thanks, Ömer

4 7

User manual
by Simon Peyton Jones 01 Jul '19

01 Jul '19

I use this link to see the most up to date GHC user manual https://ghc.gitlab.haskell.org/ghc/doc/users_guide/index.html But I think I'm seeing on from 13 June. It's labelled as GHC 8.9.0.20190613 User's Guide<https://ghc.gitlab.haskell.org/ghc/doc/users_guide/index.html> How come it's so out of date? Simon

3 3

Re:
by chessai . 01 Jul '19

01 Jul '19

Copying on ghc-devs, since i think that's what you wanted. On Mon, Jul 1, 2019, 11:14 AM Andrew Martin <andrew.thaddeus(a)gmail.com> wrote: > To get GHC to raise an exception from an inline primop, I presume that I'd > need to jump to stg_raisezh. None of the existing inline primops do > anything quite like this. I see things like emitMemcmpCall and > emitMemsetCall, but these ultimately just wrap emitForeignCall, which wraps > mkUnsafeCall, which wraps the data constructor CmmUnsafeForeignCall. I > think I want CmmCall instead, which is described by the comments as being > used for "a native call or tail call". Hmm... emitRtsCall might be what I > want. I'll try pursuing this route further. > > -- > -Andrew Thaddeus Martin > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

Re: Cloning (Shayne Fletcher)
by Jost Berthold 01 Jul '19

01 Jul '19

Just on this detail in the previous mails: On 6/25/19 10:00 PM, ghc-devs-request(a)haskell.org wrote: >> More generally, I'm actually wondering, why GHC's .gitsubmodules use > relative paths. Why not make them absolute? > > I continue to wonder about that and if switching to absolute paths might > remove this wrinkle. Can anyone chime in? I remember the relative paths for submodules were added to make working with several clones of the GHC repo (to lower rebuild cost for simultaneous branches or similar) easier. With relative paths, one can make a second local clone from the first one and all references to all submodules will share local data. That said, this does get in the way sometimes. I changed back to absolute paths in my GHC fork quite a while back. / Jost

3 2

Re: Vector registers assumed to be caller or callee-saved?
by Andreas Klebinger 30 Jun '19

30 Jun '19

What you want is not the macro but this function: https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callCl… whose results depend on the System ABI. Cheers, Andreas > Hi all, > > I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used > by the STG machine: are those assumed to be caller or callee-saved? Only for > the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in > includes/stg/MachRegs.h. However, I cannot find any other place where those > macros are used. AFAIK most C ABIs assume that vector registers are call > clobbered. Is this also the case for GHC? > > Many thanks in advance, > Stefan >

2 2

Workflow question
by Andreas Klebinger 29 Jun '19

29 Jun '19

I your situation I would just create a base commit with the (empty) files you intend to add. Then you should not need to reconfigure to build at least. However it sounds like there is nothing stopping you from just building stage1 with a working base commit, then freezing and iterating on stage2 and testing on non-ghc test cases. It's what I usually do.

1 0

Why is NoExt inhabited?
by Ben Gamari 29 Jun '19

29 Jun '19

Hi Shayan, During code review a contributor asked about a TTG extension point. While answering his question I realized I didn't have a good explanation for why NoExt is inhabited; as far as I can tell it should rather be unhabited. If there is a reason for this then can you: 1. describe why this is so in #16863 [1] 2. open an MR documenting the reason in Note [Trees that Grow]. If not, perhaps we should consider changing it; the current state of things is a bit awkward. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/16863

4 4

Vector registers assumed to be caller or callee-saved?
by Stefan Schulze Frielinghaus 29 Jun '19

29 Jun '19

Hi all, I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used by the STG machine: are those assumed to be caller or callee-saved? Only for the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in includes/stg/MachRegs.h. However, I cannot find any other place where those macros are used. AFAIK most C ABIs assume that vector registers are call clobbered. Is this also the case for GHC? Many thanks in advance, Stefan

1 0