GitLab

There are still some fixes required to get the threaded RTS compilable
with the NCG, and apparently there are problems on 32-bit archs too.

HEAD doesn't z-encode external-core output (unlike 6.4). I suppose, that
this is unwanted behaviour. It probably results from this patch:

========================================================================
Fri Jan  6 17:30:19 CET 2006  simonmar
  * [project @ 2006-01-06 16:30:17 by simonmar]
  Add support for UTF-8 source files

[...]    

Z-encoding has been moved right to the back end.  Previously we
used to Z-encode every identifier on the way in for simplicity,
and only decode when we needed to show something to the user.
Instead, we now keep every string in its UTF-8 encoding, and
Z-encode right before printing it out.

[...]
========================================================================

Greetings
Jan

Hello, this is my first patch contributed to GHC. If there are any
inadequacies about it (maybe like this introductory disclaimer), please
let me know about it.

So, the need for this patch arose, while I was involved with processing
hcr files (external core output) and I noticed, that the output didn't
fully conform to the specification [1].
No %local-tags were used, which turned out to be a real nuisance as it
was not possible to determine which VDEFs can be erased in a further
optimization process and which ones are exported by the module.

Since the specification does not define the meaning of the %local-tag, I
assume, it makes sense, that it tags all functions, that are not
exported by the module.

The patch does not fully comply to the specification, as in my
implementation a local tag may appear before a VDEF but not before a
VDEFG.

[1] An External Representation for the GHC Core Language
    (DRAFT for GHC5.02), page 3, line 1

Greetings
Jan

darcs-all may now be run with any POSIX-compatible /bin/sh.

say "{-# SOURCE #-}" rather than "{- SOURCE -}" in warning message.
Fixes http://hackage.haskell.org/trac/ghc/ticket/812

This appears to be a long-standing bug, discovered by BlueSpec 
(ravi@bluespec.com), Trac bug #795

The problem was that in an IP binding group, the dict bindings
aren't necessarily in dependency order; and if they aren't 
we get a core-lint error.

Test tc203 checks this case.  (Though whether it shows up at
all depends a bit on accidental factors of binding ordering.)

Fixes #809

static relative offsets (eg .long l1-l2) are restricted to 32 bits on
x86-64 due to lack of support in the linker.  The codegen, NCG and
runtime work around this, using 32-bit offsets instead of 64.
However, we were missing a workaround for vector tables, and it
happened to work by accident because the offsets were always positive
and resolved by the assembler.  The bug was exposed by using the NCG
to compile the RTS, where the offsets became negative, again by
accident.

So that we can build the RTS with the NCG.

so that we can calculate deterministic offsets to some of the fields
of Capability.

gmp.h #defines mpz_foo to __gmpz_foo, so the real ABI is __gmpz_foo,
so that is what we must invoke in order to be portable here.
Similarly for mpn --> __gmpn.

We weren't handling InBoth properly.  InBoth needs to be expanded to
appropriate InReg/InMem locations *before* building the interference
graph, otherwise an InBoth will not be seen to conflict with other
InReg/InMem locations.

This will let us express write barriers in C--

as a precautionary measure.  It is definitely required for GC.c,
but it may well become necessary for other files in the future due to
our (mis-)use of the C "type system".

In SpecConstr.scBind, we should pass the optimised body (body') to
specialise, not the un-optimised one. In this way we'll benefit from
specialising any nested functions inside body.

Discovered by Roman.

For some reason, SpecConstr wasn't taking account of let-bound constructors:
	let v = Just 4
	in ...(f v)...

Now it does.  An easy fix fortunately.

This patch arranges that derived instances use the same instance-decl
checking code as user-defined instances.  That gives greater consistency
in error messages.

Furthermore, the error description if this consistency check fails is now
much more explicit.  For example, drvfail003 now says
     Variable occurs more often in a constraint than in the instance head
       in the constraint: Show (v (v a))
     (Use -fallow-undecidable-instances to permit this)
     In the derived instance
       instance (Show (v (v a))) => Show (Square_ v w a)

Consider this example (provided by Roman)

	foo :: Int -> Maybe Int -> Int
	foo 0 (Just n) = n
	foo m (Just n) = foo (m-n) (Just n)

SpecConstr sees this fragment:

	case w_smT of wild_Xf [Just A] {
	  Data.Maybe.Nothing -> lvl_smf;
	  Data.Maybe.Just n_acT [Just S(L)] ->
	    case n_acT of wild1_ams [Just A] { GHC.Base.I# y_amr [Just L] ->
	    $wfoo_smW (GHC.Prim.-# ds_Xmb y_amr) wild_Xf
	    }};

and correctly generates the rule

	RULES: "SC:$wfoo1" [0] __forall {y_amr [Just L] :: GHC.Prim.Int#
					  sc_snn :: GHC.Prim.Int#}
	  $wfoo_smW sc_snn (Data.Maybe.Just @ GHC.Base.Int (GHC.Base.I# y_amr))
	  = $s$wfoo_sno y_amr sc_snn ;]

BUT we must ensure that this rule matches in the original function!
Note that the call to $wfoo is
	    $wfoo_smW (GHC.Prim.-# ds_Xmb y_amr) wild_Xf

During matching we expand wild_Xf to (Just n_acT).  But then we must also
expand n_acT to (I# y_amr).  And we can only do that if we look up n_acT
in the in-scope set, because in wild_Xf's unfolding it won't have an unfolding
at all. 

Happily, fixing the bug is easy: add a call to 'lookupRnInScope' in the 
(Var v2) case of 'match'.

Happy, Alex and Haddock are built separately using Cabal now.