GitLab

Wibble to typerep (fixes crash I hope)

fix repType after changes to the representation of type synonyms.
This caused the stage2 compiler to crash, because various info tables
misrepresented the pointerhood of constructor arguments.

something has gone wrong; I don't have time right now to find out
exactly what, so revert rev. 1.22 in an attempt to fix it.

fix threaded build

Two improvements to the SMP runtime:

  - support for 'par', aka sparks.  Load balancing is very primitive
    right now, but I have seen programs that go faster using par.

  - support for backing off when a thread is found to be duplicating
    a computation currently underway in another thread.  This also
    fixes some instability in SMP, because it turned out that when
    an update frame points to an indirection, which can happen if
    a thunk is under evaluation in multiple threads, then after GC
    has shorted out the indirection the update will trash the value.
    Now we suspend the duplicate computation to the heap before this
    can happen.

Additionally:

  - stack squeezing is separate from lazy blackholing, and now only
    happens if there's a reasonable amount of squeezing to be done
    in relation to the number of words of stack that have to be moved.
    This means we won't try to shift 10Mb of stack just to save 2
    words at the bottom (it probably never happened, but still).

  - update frames are now marked when they have been visited by lazy
    blackholing, as per the SMP paper.

  - cleaned up raiseAsync() a bit.

cosmetic

Add wcStore(), a write-combining store if supported

(I tried using it in the update code and only succeeded in making
things slower, but it might come in handy in the future)

cosmetic

Omit the __DISCARD__() call in FB_ if __GNUC__ >= 3.  It doesn't
appear to be necessary now, and it prevents some gcc optimisations.

Discard various ways in which gcc zeroes stack slots in the prologue.
So far in my investigations these have always been unnecessary, they
appear to be the result of missed optimisations by gcc, so cross
fingers and discard them.  New variants have just shown up because I
started compiling the RTS with -optc-O2.

small improvement to the update code

Use -optc-O2 when compiling the RTS

Separate the documentation for Concurrent Haskell from that for
Parallel Haskell, and put a big note at the top of the Parallel
Haskell section pointing to the GPH site.

small fixes to docs for +RTS -C

Better error reporting for newtypes with too many constructors,
or too many fields.  Instead of yielding a parse error, we
parse it like a data type declaration, and give a comprehensible
error message later.

A suggestion from Jan-Willem.

Two significant changes to the representation of types

1. Change the representation of type synonyms

    Up to now, type synonym applications have been held in
    *both* expanded *and* un-expanded form.  Unfortunately, this
    has exponential (!) behaviour when type synonyms are deeply
    nested.  E.g.
	    type P a b = (a,b)
	    f :: P a (P b (P c (P d e)))
    
    This showed up in a program of Joel Reymont, now immortalised
    as typecheck/should_compile/syn-perf.hs

    So now synonyms are held as ordinary TyConApps, and expanded
    only on demand.  

    SynNote has disappeared altogether, so the only remaining TyNote
    is a FTVNote.  I'm not sure if it's even useful.

2. Eta-reduce newtypes

    See the Note [Newtype eta] in TyCon.lhs
    
    If we have 
	    newtype T a b = MkT (S a b)
    
    then, in Core land, we would like S = T, even though the application
    of T is then not saturated. This commit eta-reduces T's RHS, and
    keeps that inside the TyCon (in nt_etad_rhs).  Result is that 
    coreEqType can be simpler, and has less need of expanding newtypes.

Yet more detail in types with -dppr-debug

Move the building guide to GHC where it belongs. This is more consistent and
currently even necessary, otherwise *every* fptools project would need the ghc
subtree.

Better TH -> HsSyn conversion

	Merge to stable (attempt)

This commit monad-ises the TH syntax -> HS syntax conversion.
This means that error messages can be reported in a more civilised
way.  It also ensures that the entire structure is converted eagerly.
That means that any exceptions buried inside it are triggered 
during conversion, and caught by the exception handler in TcSplice.
Before, they could be triggered later, and looked like comiler
crashes.

Fix a crash in STM; we were releasing ownership of the transaction too
early in stmWait(), so a TSO could be woken up before we had finished
putting it to sleep properly.

- point to the bug tracker from the "known bugs" section
- move the item about instances from GHCi to GHC, and tweak it a bit

make validate happy

oops, it's i386_TARGET_ARCH, not x86_TARGET_ARCH

SMP bugfix: if the thread we were just running blocked, then we are in
a delicate state - we don't necessarily have access to the TSO we were
just running, because we relinquished it when we put it on whatever
blocking queue it is on.  It might even be running already.

Previously I made the scheduler quickly loop again in this case.
However, I made it loop too quickly: we should be sure to set the
blackholes_need_checking flag if necessary, otherwise we can miss some
wakeups.

more docs for GHC_PACKAGE_PATH

when GHC_PACKAGE_PATH is set, treat the database at the bottom of the
stack as the "global" one, ie. the one we modify by default.  This
means that GHC_PACKAGE_PATH can be used to set up a virtual GHC
package environment into which packages can be installed using Cabal,
without setting anything other than GHC_PACKAGE_PATH.

gcc's -fstrict-aliasing is biting us when we use the stack to store
different types of objects.  For example:

  *((StgDouble*)((W_)Sp-8)) = *((StgDouble*)((W_)Sp+8));
  Sp[1] = (W_)&s1Cx_info;

gcc feels free to reorder these two lines, because they refer to
differently typed objects, even though the assignment to Sp[1] clearly
aliases the read from the same location.

Trying to fix this by accessing locations using union types might be
possible, but I took the sledgehammer approach of
-fno-strict-aliasing.  This is justified to a certain extent because
our generated C code is derived from a very weakly-typed internal
language (C--).

unless I'm mistaken, only x86 needs -ffloat-store.  x86_64 certainly
doesn't need it, because it uses SSE2 with the correct-sized floating
point registers and doesn't store temporary results with more
precision than results in memory.

Fix bug in an assertion

raiseAsync: fix bug that can cause a scavenge_stack panic for a thread
that has just been killed.

Fix some problems with array thawing/freezing and the GC.

Fix non-threaded build.

fix for pre-6.0 ghc's

Document GHC_PACKAGE_PATH, and changes to the ghc-pkg command line interface.

- Add support for the GHC_PACKAGE_PATH environment variable, which
  specifies a :-separated (;-separated on Windows) list of package
  database files.  If the list ends in : (; on Windows), then the
  normal user and global databases are added.

  GHC_PACKAGE_PATH is searched left-to-right for packages, like
  $PATH, but unlike -package-conf flags, which are searched
  right-to-left.  This isn't ideal, but it seemed the least worst to me
  (command line flags always override right-to-left (except -i),
  whereas the PATH environment variable overrides left-to-right, I chose
  to follow the environment variable convention).  I can always change
  it if there's an outcry.

- Rationalise the interpretation of --user, --global, and -f on the
  ghc-pkg command line.  The story is now this: --user and --global
  say which package database to *act upon*, they do not change the
  shape of the database stack.  -f pushes a database on the stack, and
  also requests that the specified database be the one to act upon, for
  commands that modify the database.  If a database is already on the stack,
  then -f just selects it as the one to act upon.

  This means you can have a bunch of databases in GHC_PACKAGE_PATH, and
  use -f to select the one to modify.

patch up forkProcess(): don't discard our own Task, and set
cap->spare_workers to be empty in the child process.

We shouldn't call closeCondition() on the condition in discardTask(),
we're just freeing the Task for later use.

Win32: Use CriticalSections instead of Mutexes, they are *much* faster.

adjust type of startSignalHandlers() to make changes to Win32 version

schedulePushWork(): don't attempt to move the thread bound to the
current Task to a different Capability.