- ghc-devs - Haskell.org

runghc fails on Windows with GHC HEAD
by Ryan Scott 08 Dec '15

08 Dec '15

For some reason, I can't get runghc to work with GHC HEAD. Compiling with ghc-stage2 and running ghc-stage2 --interactive both work okay, it's just runghc that doesn't want to cooperate for some reason: $ .\ghc\inplace\bin\runghc.exe Z.hs runghc.exe: C:\Users\ryanscot\Documents\Software\ghc\inplace\bin\ghc: rawSystem: does not exist (No such file or directory) Does anyone have an idea of what might be happening here? Ryan S.

1 0

Non-exported class constraints in errors
by David Feuer 08 Dec '15

08 Dec '15

The latest implementation of Data.Constraint.Forall uses type family Forall (p :: k -> Constraint) :: Constraint where Forall p = Forall_ p class p (Skolem p) => Forall_ (p :: k -> Constraint) instance p (Skolem p) => Forall_ (p :: k -> Constraint) The trouble is that errors relating to Forall are reported with Skolem verbiage, making them incomprehensible to users -- the Skolem type family is not exported. It would be nice if GHC could keep track of what led to the p (Skolem p) constraint, and report that. The sanest idea I've come up with thus far is a "buck stops here" pragma. When GHC attempts to solve a constraint so marked, it will hold onto that fact, and report any failures against that. So {-# TheBuckStopsHere Forall #-} would make GHC take note when trying to solve Forall p, and report that it failed to solve Forall p, rather than that it failed to solve constraints further down the line.

1 0

Another question about -XStrict: Why not implement it as a Core pass?
by Ömer Sinan Ağacan 08 Dec '15

08 Dec '15

So this is another question comes to mind. It seems to me like it would be a lot easier to implement, we could even implement it as a plugin, without changing anything in GHC. (I mean -XStrict, not -XStrictData) I'm wondering why it's currently implemented on Haskell syntax. Any ideas? Is it because of some typechecking related things?

1 0

Submodules on a branch
by Simon Peyton Jones 08 Dec '15

08 Dec '15

· I’m on a branch wip/T11067. · I do a ‘git merge origin/master’, resolve source code conflicts and commit · Then ‘git submodule update’ · I have not touched libraries/unix · Yet when I say “git submodule” in a different HEAD tree, I get a different commit for libraries/unix than in my branch Question (sticking plaster): how can I say “Just make my sub-modules match HEAD please”? Question (cause): how can I ensure that I do update my branch to the submodule of HEAD when doing ‘git merge’? Getting submodules out of sync is very tiresome. Thanks Simon

2 1

Plugins: Accessing unexported bindings
by Levent Erkok 08 Dec '15

08 Dec '15

Hello, The mg_binds field of the ModGuts seem to only contain the bindings that are exported from the module being compiled. I guess GHC must be running user-plugins after it drops the bindings that are not exported, which makes perfect sense for most use cases. However, I'm working on a plugin where the end-programmer embeds "properties" in the form of functions inside his/her code, which are not necessarily exported from the module under consideration. Is there a way to access all top-level bindings in a module from a plugin, even if those bindings are not exported? Thanks, -Levent.

6 17

Questions concerning the LLVM backend - i.e. 'proc point splitting'
by David Spitzenberg 08 Dec '15

08 Dec '15

Hello everybody, I've got some questions concerning the LLVM backend - i.e. the pass 'proc point splitting' in the cmm-pipeline. I'm new to this list as well as to computer science in general - at least in some sense. Being a third semester student of computer science, I'm not quite sure, whether I'm addressing the right list with this mail. Feel free to correct me, if not. I'm doing numerical stencil calculations which heavily depend on nested loops expressed as tail-recursive functions nested one in another. When compiling a module, GHC seems capable of emitting pretty good cmm-code. At least as long as the loop bodies do not contain any call to non-inlineable functions. In most cases 'loopification' fires and transforms tail-recursive calls into loops. When calling into non-inlineable functions, 'proc point splitting' is performed. This splits the loops into several mutually-recursive functions therefore significantly decreasing the possibilities of 'opt' in optimizing the code later on. This leads to pretty bad performance of the whole calculation. To avoid the presence of proc points within a loop body - and by doing so the splitting of the body - I currently try to avoid calls into non-inlineable functions by merging the nested recursive functions into one giant tail-recursive function. This works, as long as everything not defined in the module being compiled can be inlined. Apparently, this is not a long term solution. My questions: - The reason to perform 'proc point splitting' is, that LLVM IR lacks of the possibility to call into an arbitrary basic block of a function body from outside the function itself. Is this understanding right? - Are there any other possibilities to avoid 'proc point splitting' when using LLVM as a backend? - I recently read the article on an improved LLVM backend in the GHC wiki (https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend) but couldn't find any suggestions on the topic of 'proc point splitting'. Are there any plans to solve the problem either by teaching LLVM IR the lacking functionality or in any other way? I'd really like to contribute to GHC by working on this problem, but I'm not quite sure, if I'm capable of doing so. My background knowledge is still somewhat limited, but I'm working on it ;-) Thanks in advance for your help! Regards, David Spitzenberg PS.: Thanks to everyone for the great work you're doing on GHC!

3 5

Allow ambiguous types (with warning) by default
by David Feuer 08 Dec '15

08 Dec '15

The ambiguity check produces errors that are quite surprising to the uninitiated. When the check is suppressed, the errors at use sites are typically much easier to grasp. On the other hand, there's obviously a lot of value to catching mistakes as soon as possible. Would it be possible to turn that into a warning by default?

6 10

RTS linker refactoring
by Sylvain Henry 08 Dec '15

08 Dec '15

Hi devs, I have made a patch to refactor the RTS linker, especially to drastically reduce its memory usage: https://phabricator.haskell.org/D1470 We need to test it on differrent OS/architectures before it can be merged. Here is the current state: - Linux/x86-64: OK (Harbormaster and I) - Solaris/x86-64: was OK, maybe needs to be retested (@kgardas) - OpenBSD/x86-64: was OK, maybe needs to be tetested (@kgardas) - Solaris/i386: was failing with unrelated error, needs to be retested (@kgardas) - Linux/PowerPC: OK (@erikd) - Linux/ARM: was failing with unrelated #11123 (@erikd), OK? (@bgamari) - Windows: ? - MacOS: ? - ia64: ? I don't have access to Windows and Mac OS boxes so I don't even know if it compiles there. Could someone test it (validate) on these OSes and report any issue they encounter to me (by mail or on phabricator)? Do we support ia64 architecture? Thanks! Sylvain

2 2

Re: [GHC] #11177: panic! tc_hs_type: record
by Alan & Kim Zimmerman 08 Dec '15

08 Dec '15

I am travelling until Thursday, will only be able to look on Friday. Alan On 08 Dec 2015 2:44 PM, "GHC" <ghc-devs(a)haskell.org> wrote: > #11177: panic! tc_hs_type: record > ---------------------------------+----------------------------- > Reporter: apanagio | Owner: > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.6.3 > Resolution: | Keywords: > Operating System: Linux | Architecture: x86 > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > ---------------------------------+----------------------------- > Changes (by simonpj): > > * cc: alanz (added) > > > Comment: > > This looks like fallout from the 'refactor `ConDecl` patch. > > Alan? > > Simon > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11177#comment:1> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

A GHC Library
by Richard Eisenberg 08 Dec '15

08 Dec '15

Hi devs, It has struck me that we have a vast trove of documentation about GHC in the form of academic papers, but little organization to this trove. The papers are scattered across authors' websites, and sometimes it is hard to remember what a paper is titled when searching for it. I have thus started a wiki page here: https://ghc.haskell.org/trac/ghc/wiki/Library I would love for this page to be the Definitive List of GHC-related papers. The list I've included is, of course, woefully short, but it is a starting point. Please add to it! Have you written a GHC paper? If so, make sure it's included. Thanks, Richard

6 12