Fix worker/wrapper for CPR functions

A long-standing and egregious bug in the worker/wrapper code meant
that some functions with the CPR property weren't getting a CPR
w/w. And that had the effect of making a tail-recursive function not
tail recursive.  As well as increasing allocation.

Fixes Trac #5920, and #5997.

Nofib results (highlights):

        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
         boyer2          -0.1%    -15.3%      0.01      0.01     +0.0%
        mandel2          -0.0%     -8.1%      0.01      0.01     +0.0%
           para          -0.1%    -11.8%     -7.9%     -7.8%     +0.0%
--------------------------------------------------------------------------------
            Min          -0.1%    -15.3%     -7.9%     -7.8%    -33.3%
            Max          +0.0%     +0.2%     +6.3%     +6.3%     +3.7%
 Geometric Mean          -0.0%     -0.4%     +0.1%     +0.1%     -0.5%

Looks like a clear win.  And I have not even recompiled the libraries, so
it'll probably be a bit better in the ed.

MERGED from commit b8ff4448d899f783fc112f3774aab626979a4f22
Flags documentation: -fwarn-unrecognized-pragmas is enabled by -Wall (#6050)

MERGED from commit 44098b3dab032a83cc869855de67377f41d82384
Doc: updated list of warnings not enabled by -Wall (#4817)

MERGED from commit 18c2a2f71e38fad5e677b8f448f6135e5a691868
Compile link .note section separately from main.c

Fixes gas errors when -g is enabled:

Error: can't resolve `.debug-ghc-link-info' {.debug-ghc-link-info section} - `.Ltext0' {.text section}
Omit -osuf/-odir -hisuf/-hidir and -stubdir from the flag checker

The reasoning is that GHC will only skip recompilation if it has found
a valid up-to-date object file and .hi file, so there is no need to
also check that these flags have not changed, and indeed there are
valid reasons to want to change them.
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