Cast memory primops in the C backend (#5976)

To prevent conflicts with GCC builtins, generate identical code for
calls to mem primos and FFI calls.

Based on a patch by Joachim Breitner.
MERGED from commit 40c1106c338e209f07023d165f32bff0f75e2e54
hs_init(): cope with argc and/or argv being NULL (#6006)

MERGED from commit 4ca281829c70331571291ed3dcf813a6028cc904
Catch illegal imports earlier (#6007)

MERGED from commit b6e28266cf29bfdf07fe08e894df77b400da8a04
Build fix.
Update 7.4.2 release notes.
Fix typo in 7.4.2 release notes.
MERGE: Be less aggressive about the result discount

Merge of:
    commit 4fa3f16ddb9fa8e5d59bde5354918a39e0430a74
    Author: Simon Peyton Jones <simonpj@microsoft.com>
    Date:   Mon May 28 17:33:42 2012 +0100

Be less aggressive about the result discount

This patch fixes Trac #6099 by reducing the result discount in CoreUnfold.conSize.
See Note [Constructor size and result discount] in CoreUnfold.

The existing version is definitely too aggressive. Simon M found it an
"unambiguous win" but it is definitely what led to the bloat. In a function
with a lot of case branches, all returning a constructor, the discount could
grow arbitrarily large.

I also had to increase the -funfolding-creation-threshold from 450 to 750,
otherwise some functions that should inline simply never get an unfolding.
(The massive result discount was allow the unfolding to appear before.)

The nofib results are these, picking a handful of outliers to show.

        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
         fulsom          -0.5%     -1.6%     -2.8%     -2.6%    +31.1%
       maillist          -0.2%     -0.0%      0.09      0.09     -3.7%
         mandel          -0.4%     +6.6%      0.12      0.12     +0.0%
       nucleic2          -0.2%    +18.5%      0.11      0.11     +0.0%
        parstof          -0.4%     +4.0%      0.00      0.00     +0.0%
--------------------------------------------------------------------------------
            Min          -0.9%     -1.6%    -19.7%    -19.7%     -3.7%
            Max          +0.3%    +18.5%     +2.7%     +2.7%    +31.1%
 Geometric Mean          -0.3%     +0.4%     -3.0%     -3.0%     +0.2%

Turns out that nucleic2 has a function
  Main.$wabsolute_pos =
    \ (ww_s4oj :: Types.Tfo) (ww1_s4oo :: Types.FloatT)
      (ww2_s4op :: Types.FloatT) (ww3_s4oq :: Types.FloatT) ->
      case ww_s4oj
      of _
      { Types.Tfo a_a1sS b_a1sT c_a1sU d_a1sV e_a1sW f_a1sX g_a1sY h_a1sZ i_a1t0 tx_a1t1 ty_a1t2 tz_a1t3 ->
      (# case ww1_s4oo of _ { GHC.Types.F# x_a2sO ->
         case a_a1sS of _ { GHC.Types.F# y_a2sS ->
         case ww2_s4op of _ { GHC.Types.F# x1_X2y9 ->
         case d_a1sV of _ { GHC.Types.F# y1_X2yh ->
         case ww3_s4oq of _ { GHC.Types.F# x2_X2yj ->
         case g_a1sY of _ { GHC.Types.F# y2_X2yr ->
         case tx_a1t1 of _ { GHC.Types.F# y3_X2yn ->
         GHC.Types.F#
           (GHC.Prim.plusFloat#
              (GHC.Prim.plusFloat#
                 (GHC.Prim.plusFloat#
                    (GHC.Prim.timesFloat# x_a2sO y_a2sS)
                    (GHC.Prim.timesFloat# x1_X2y9 y1_X2yh))
                 (GHC.Prim.timesFloat# x2_X2yj y2_X2yr))
              y3_X2yn)
         } } }}}}},

        <similar>,
        <similar> )

This is pretty big, but inlining it does get rid of that F# allocation.
But we'll also get rid of it with deep CPR: Trac #2289. For now we just
accept the change.
Update ANNOUNCE for 7.4.1
Set RELEASE to YES, and version to 7.4.2
escape(): don't forget the final '\0'

Hopefully should fix random "bad heap profile" failures in the nightly
builds.

MERGED from commit 634fb8d3b569276504be317783ade54508633b10
Tabs -> Spaces in GhcMake.hs.
checkStability: respect -fforce-recomp (#6105)

MERGED from commit c95342cef63fad2edfaf3868de11ff7781b440c8
Read the source file timestamp *before* preprocessing (#6106)

MERGED from commit d82da293078b00d0f2d85c947e70382d398aab64
Set RELEASE back to NO
Fix for earger blackholing of thunks with no free variables (#6146)

A thunk with no free variables was not getting blackholed when
-feager-blackholing was on, but we were nevertheless pushing the
stg_bh_upd_frame version of the update frame that expects to see a
black hole.

I fixed this twice for good measure:

 - we now call blackHoleOnEntry when pushing the update frame to check
   whether the closure was actually blackholed, and so that we use the
   same predicate in both places

 - we now black hole thunks even if they have no free variables.
   These only occur when optimisation is off, but presumably if you say
   -feager-blackholing then that's what you want to happen.

MERGED from commit 21a53a1cd5a9784aca7b78cc972f917e71938124
throwTo: unlock the MSG_THROWTO object before returning (#6103)

MERGED from commit 20ba7f1a7a7b05acd81124f1567a3a103bcd0d1b
Fix ref to ticket in 7.4.2 release notes.
Drop the per-task timing stats, give a summary only (#5897)

We were keeping around the Task struct (216 bytes) for every worker we
ever created, even though we only keep a maximum of 6 workers per
Capability.  These Task structs accumulate and cause a space leak in
programs that do lots of safe FFI calls; this patch frees the Task
struct as soon as a worker exits.

One reason we were keeping the Task structs around is because we print
out per-Task timing stats in +RTS -s, but that isn't terribly useful.
What is sometimes useful is knowing how *many* Tasks there were.  So
now I'm printing a single-line summary, this is for the program in

  TASKS: 2001 (1 bound, 31 peak workers (2000 total), using -N1)

So although we created 2k tasks overall, there were only 31 workers
active at any one time (which is exactly what we expect: the program
makes 30 safe FFI calls concurrently).

This also gives an indication of how many capabilities were being
used, which is handy if you use +RTS -N without an explicit number.

MERGED from commit 085c7fe5d4ea6e7b59f944d46ecfeba3755a315b
Build fix for Hurd.

Patch by Samuel Thibault.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659530.

MERGED from commit d2b538c80c00a99a51e4892dec475eae38cf9888
Don't put auto sccs on INLINE functions (#6131)

There was also a bug caused by INLINEs getting SCCs, but unfortunately
I have lost the test case.  The Note in the code describes the problem
though.

MERGED from commit 6181e007f0e1e8eddba7acf0d5fbcbaf46806249