GitLab

$ ./inplace/bin/ghc-stage2 --interactive
GHCi, version 6.11.20090701: http://www.haskell.org/ghc/  :? for help
ghc-stage2: GHCi cannot be used when compiled with -prof
[1]    32473 exit 1     ./inplace/bin/ghc-stage2 --interactive

Building a profiled GHC is as simple as adding

GhcLibWays += p
GhcProfiled = YES

to your build.mk and saying 'make'.  Then you have a profiled
inplace/bin/ghc-stage2.

 - converting a THSyn FFI declaration to HsDecl was broken; fixed
 - pretty-printing of FFI declarations was variously bogus; fixed
 - there was an unused "library" field in CImport; removed

I boobed when I decoupled record selectors from their data types.
The most straightforward and robust fix means attaching the TyCon
of a record selector to its IfaceIdInfo, so 

   you'll need to rebuild all .hi files

That said, the fix is easy.

In particular, in the integer-gmp package the C and CMM code depends
on the size of STG structures, which vary between ways.

Behind the scenes, the new IO library always does buffering for read
Handles regardless of NoBuffering.  Normally this isn't visible, but
it causes a problem in GHCi where there are two stdin Handles.

This should fix those ghci test failures that sprung up in full
testsuite runs recently.

Previously this rule had a sanity check for the existence of the .o
file.  However, the sanity check is expensive, especially on Windows,
because it requires spawning a shell.  So now we use an empty command
here.

This change reduced the time to do 'make' in an up-to-date tree on
Windows from 33s to 16s for me.  (the actual saving depends on how
much rebuilding you've been doing, and how many .hi files are older
than their .o files).

The comments in this file now describe various versions of the rule
that don't work.

integer-gmp's Integer is now wrapped by an Integer type in integer.

Fixes ghci loading gmp on Windows

When configure tests for a feature it may not generate warning-free C
code, and thus may think that the feature doesn't exist if -Werror is
on.

Nothing from gmp is used in the rts anymore.

and remove the implementations of stg(Alloc|Realloc|Dealloc)ForGMP

The implementations are still in the rts.

In particular we need alloc_blocks and alloc_blocks_lim for MAYBE_GC.
The gmp cmm primops also use stg_ARR_WORDS_info.

We need this, or something equivalent, to be able to implement
stgAllocForGMP outside of the rts. That's because we want to use
allocateLocal which allocates from the given capability without
having to take any locks. In the gmp primops we're basically in
an unsafe foreign call, that is a context where we hold a current
capability. So it's safe for us to use allocateLocal. We just
need a way to get the current capability. The method to get the
current capability varies depends on whether we're using the
threaded rts or not. When stgAllocForGMP is built inside the rts
that's ok because we can do it conditionally on THREADED_RTS.
Outside the rts we need a single api we can call without knowing
if we're talking to a threaded rts or not, hence this addition.