Remove uses of stderr from .cmm code.

We can't reliably refer to stdin/stdout/stderr from .cmm, because the
C standard doesn't specify whether stderr is a variable or a macro.

Add comment

newTempName: instead of bumping the processId until we find a name
that isn't used, add an integer suffix to the processId.  This should
prevent temp-file conflicts that appear to have been affecting our
nightly builds and occasionally make -j.

The right way to allocate a temporary file is to create it straight
away, but I'm not sure of the implications of passing existing
temporary files to the various sub-processes that GHC executes, hence
this fix instead.

resetStaticObjectForRetainerProfiling: catch up changes in ClosureMacros.h

When chasing explicit imports, we now look for the module in both the
home package and external packages, and complain if it is found in
both:

Chasing modules from: Overlap
Cannot import `List':
  it was found in both overlap/List.hs and package haskell98-1.0.
  Possible fix: -ignore-package haskell98-1.0
  (imported from overlap/Overlap.hs)

Previously the home module would have been ignored in favour of the
package module.  It means we're doing a bit more searching, but the
behaviour is less obscure.

Back out previous revision.

It appears that passing -g to the assembly phase of C compilation
results in an object file with broken debug info, that gdb can't
read.  This is probably a bug in gcc and/or binutils, but this change
means that I can't avoid it (unless we were to hack the pipeline to
do .c->.s->.o in one stage instead of two).

Add entry about non-blocking stdin and System.Cmd.{system,rawSystem}.

runSomething: 'rawSystem' might raise an exception to indicate that
'pgm' couldn't be executed, so catch this here & report.

Merge to STABLE.

scavenge_one: fix reversed PAP/AP cases

Partial support for deadlock detection in the threaded/SMP RTS.

The idea is to wait until a complete time slice has gone by without
running any Haskell code, and then try doing a GC to detect deadlocked
threads.

This kind of works: but we can only wake up a worker thread from the
signal handler if there's another worker running - we can't wake up the
current thread, it seems.

interruptStgRts: call threadRunnable().  This might not work properly
from a signal handler, but it's all we can do (and seems to do
something reasonable on Linux).

atomicModifyMutVarzh_fast: move the sm_mutex acquisition *after* the
heap check

Yet another StgClosure that should be StgThunk

stg_raise: we should by using StgThunk_payload(), not StgClosure_payload()

Requested by Duncan Coutts: -optc flags get passed to the assembler
phase too.  It's not obvious, when using GHC to compile a .c file,
that options need to be passed both with -optc and -opta - gcc doesn't
need this, for example.

This is an experimental change - if it breaks anything we can back it
out.  If anyone needs to pass flags to the .c->.s phase *only*, then
we will need to add another flag for that purpose.  It seems unlikely,
though (there aren't many flags that affect the assembler only, and
those that do don't conflict with flags for the C phase).

daVinci is now called uDraw(Graph)

Fix bogus uses of C variable stable_ptr_table exposed by recent fix to
C backend.

Warning police (unused parameter)

Nuked dead code

No -optc prefix fot GhcRtsCcOpts needed

Fix comment

ATTENTION: Make it compile again, but only via a wild and probably
wrong guess which might break GHCi. SimonM, please have a look at
this. (Who broke it should fix it! :-)

tweak to handle ghc-6.1 compilation. Merge to STABLE

added ghc_ge_602. Merge to STABLE

Don't split in here

Fix a comment

enable splitting on x86_64

splitting support on x86_64

fix uses of stderr

Switch to a manual-reset event for the completed-console-event object;
with auto-reset, we ran the risk of leaving it in a signalled state.

Merge to STABLE.

Switch away from using _spawnv() to CreateProcess(); the former has the
annoying 'feature' that it quits upon Ctrl-C, leaving its child in the
background. Use CreateProcess() instead and avoid the Ctrl-C issue by
having the wrapper let go of its console before waiting for the sub-process
running GHCi to exit.

This still doesn't fix the issue of Ctrl-C handling when the 'ghci' wrapper
is invoked from a cygwin-based bash. cmd.exe users will hopefully see
an improvement in behaviour though.

Merge to STABLE.

[mingw only]
Better handling of I/O request abortions upon throwing an exception
to a Haskell thread. As was, a thread blocked on an I/O request was
simply unblocked, but its corresponding worker thread wasn't notified
that the request had been abandoned.

This manifested itself in GHCi upon Ctrl-C being hit at the prompt -- the
worker thread blocked waiting for input on stdin prior to Ctrl-C would
stick around even though its corresponding Haskell thread had been
thrown an Interrupted exception. The upshot was that the worker would
consume the next character typed in after Ctrl-C, but then just dropping
it. Dealing with this turned out to be even more interesting due to
Win32 aborting any console reads when Ctrl-C/Break events are delivered.

The story could be improved upon (at the cost of portability) by making
the Scheduler able to abort worker thread system calls; as is, requests
are cooperatively abandoned. Maybe later.

Also included are other minor tidyups to Ctrl-C handling under mingw.

Merge to STABLE.

oops;supposed to have been included with revert-back-to-__stginit-for-mingw commit

resetStaticObjectForRetainerProfiling(): warning wibble

Until the GHCi linker is made capable of handling .ctors sections in
PEi object files, stick with __stginits. Being a bit sloppy by
using 'mingw32_HOST_OS' to test for this.

Fix creation of raise_info closures: they're THUNKs

evacuate(): fix THUNK case

checkSanity: fix bug in nursery checking

SAVE_EVERYTHING: for some reason we used R10.w rather than R10 in this
macro, which just broke with the change to the C backend.

- Now that labels are always prefixed with '&' in .hc code, we have to
  fix some sloppiness in the RTS .cmm code.  Fortunately it's not too
  painful.

- SMP: acquire/release the storage manager lock around
  atomicModifyMutVar#.  This is a hack: atomicModifyMutVar# isn't
  atomic under SMP otherwise, but the SM lock is a large sledgehammer.
  I think I'll apply the sledgehammer to the MVar primitives too, for
  the time being.