Bug #9439: Ensure that stage 0 compiler isn't affected

Summary:
Bug #9439 will cause miscompilation of GHC's LLVM backend. Here we
ensure that an affected compiler isn't used to bootstrap.

Test Plan: Attempt to bootstrap GHC with an affected stage 0 compiler.

Reviewers: rwbarton, austin

Reviewed By: austin

Subscribers: simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D159

(cherry picked from commit bbd031134a571c1020945b2548e3fc4795b5047a)
rts/Linker.c: declare 'deRefStablePtr' as an exported 'rts' symbol

    $ inplace/bin/ghc-stage2 -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -optc-fno-builtin -fno-ghci-history \
        testsuite/tests/ffi/should_run/T4038.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS

    *Main> main
    <interactive>: /tmp/ghc16668_0/ghc16668_5.o: unknown symbol `deRefStablePtr'

The reference to 'deRefStablePtr' is generated by 'compiler/deSugar/DsForeign.lhs':
    the_cfun
       = case maybe_target of
          Nothing    -> text "(StgClosure*)deRefStablePtr(the_stableptr)"
          Just hs_fn -> char '&' <> ppr hs_fn <> text "_closure"

Patch fixes all broken tests using 'import wrapper':
    TEST="ffi013 ffi010 ffi011 ffi005 ffi020 ffi006 ffi019 fed001 T1679 T4038"

Tests manifested as broken only in DYNAMIC_GHC_PROGRAMS=NO builds,
where GHCi's custom linker is used instead of system's linker.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit 104a66a461f4f89b8e5ad9c829923bb7ca8ceddb)
UNREG: fix emission of large Integer literals in C codegen

Summary:
On amd64/UNREG build there is many failing tests trying
to deal with 'Integer' types.

Looking at 'integerConversions' test I've observed
invalid C code generated by GHC.

Cmm code
    CInt a = -1; (a == -1)
yields 'False' with optimisations enabled via the following C code:
    StgWord64 a = (StgWord32)0xFFFFffffFFFFffffu; (a == 0xFFFFffffFFFFffffu)

The patch fixes it by shrinking emitted literals to required sizes:
    StgWord64 a = (StgWord32)0xFFFFffffu; (a == 0xFFFFffffu)

Thanks to Reid Barton for tracking down and fixing the issue.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: validate on UNREG build (amd64, x86)

Reviewers: simonmar, rwbarton, austin

Subscribers: hvr, simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D173

(cherry picked from commit 43f1b2ecd1960fa7377cf55a2b97c66059a701ef)
driver: pass '-fPIC' option to assembler as well

Summary:
Before the patch '-fPIC' was passed only to C compiler,
but not to assembler itself.

It led to runtime crash in GHC_DYNAMIC_PROGRAMS=YES mode
on sparc32.

Technical details are in 'Note [-fPIC for assembler]'.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: validate on sparc

Reviewers: simonmar, austin, kgardas

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D177

(cherry picked from commit a93ab43ab5f40cadbedea2f6342b93c245e91434)
pprC: declare extern cmm primitives as functions, not data

Summary:
  The commit fixes incorrect code generation of
  integer-gmp package on ia64 due to C prototypes mismatch.
  Before the patch prototypes for "foreign import prim" were:
      StgWord poizh[];
  After the patch they became:
      StgFunPtr poizh();

Long story:

Consider the following simple example:

    {-# LANGUAGE MagicHash, GHCForeignImportPrim, UnliftedFFITypes #-}
    module M where
    import GHC.Prim -- Int#
    foreign import prim "poizh" poi# :: Int# -> Int#

Before the patch unregisterised build generated the
following 'poizh' reference:
    EI_(poizh); /* StgWord poizh[]; */
    FN_(M_poizh_entry) {
    // ...
    JMP_((W_)&poizh);
    }

After the patch it looks this way:
    EF_(poizh); /* StgFunPtr poizh(); */
    FN_(M_poizh_entry) {
    // ...
    JMP_((W_)&poizh);
    }

On ia64 it leads to different relocation types being generated:
  incorrect one:
    addl r14 = @ltoffx(poizh#)
    ld8.mov r14 = [r14], poizh# ; r14 = address-of 'poizh#'
  correct one:
    addl r14 = @ltoff(@fptr(poizh#)), gp ; r14 = address-of-thunk 'poizh#'
    ld8 r14 = [r14]

'@fptr(poizh#)' basically instructs assembler to creates
another obect consisting of real address to 'poizh' instructions
and module address. That '@fptr' object is used as a function "address"
This object is different for every module referencing 'poizh' symbol.

All indirect function calls expect '@fptr' object. That way
call site reads real destination address and set destination
module address in 'gp' register from '@fptr'.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit e18525fae273f4c1ad8d6cbe1dea4fc074cac721)
Fix a rare parallel GC bug

When there's a conflict between two threads evacuating the same TSO,
in some cases we would update the incall->tso pointer to point to the
wrong copy of the TSO.  This would get fixed during the next GC, but
if the thread completed in the meantime, it would likely crash.  We're
seeing this about once per day on a heavily loaded machine (it varies
a lot though).

(cherry picked from commit a11f71eff15ba2706cbb2ee29aaf7350909e0d2f)