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)
systools: fix gcc version detecton on non-english locale

Summary:
ghc runs 'gcc -v' to check if we run under vanilla gcc
or disaguised clang by checking for string

    "gcc version <something>"

But this check does not always work as gcc has that string
localized via gettext mechanism:

    (some gcc's locale strings)
    be.po-msgstr "версія gcc %s\n"
    da.po-msgstr "GCC version %s\n"
    de.po-msgstr "gcc-Version %s %s\n"
    el.po-msgstr "έκδοση gcc %s\n"
    ...

To ping gcc to English locale we now override environment
variable with 'LANGUAGE=en' value.

Fixes Issue #8825

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

Test Plan: validate

Reviewers: austin

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

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

GHC Trac Issues: #8825

(cherry picked from commit 4d4d07704ee78221607a18b8118294b0aea1bac4)
Take account of the AvailTC invariant when importing

In the rather gnarly filterImports code, someone had forgotten
the AvailTC invariant:  in AvailTC n [n,s1,s2], the 'n' is itself
included in the list of names.

(cherry picked from commit f964cd9c5c411f8a2383cf2b080581a5c3349661)
Include pattern synonyms as AConLikes in the type environment,
even for simplified/boot ModDetails (fixes #9417)

(cherry picked from commit f0db1857b053597e9ac43d9ce578e5f5fa0545cb)
x86: zero extend the result of 16-bit popcnt instructions (#9435)

Summary:
The 'popcnt r16, r/m16' instruction only writes the low 16 bits of
the destination register, so we have to zero-extend the result to
a full word as popCnt16# is supposed to return a Word#.

For popCnt8# we could instead zero-extend the input to 32 bits
and then do a 32-bit popcnt, and not have to zero-extend the result.
LLVM produces the 16-bit popcnt sequence with two zero extensions,
though, and who am I to argue?

Test Plan:
 - ran "make TEST=cgrun071 EXTRA_HC_OPTS=-msse42"
 - then ran again adding "WAY=optasm", and verified that
   the popcnt sequences we generate match the ones produced
   by LLVM for its @llvm.ctpop.* intrinsics

Reviewers: austin, hvr, tibbe

Reviewed By: austin, hvr, tibbe

Subscribers: phaskell, hvr, simonmar, relrod, ezyang, carter

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

GHC Trac Issues: #9435

(cherry picked from commit 64151913f1ed32ecfe17fcc40f7adc6cbfbb0bc1)
testsuite: T7815 requires SMP support from ghc

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit ff9f4ad38521e54c5284f9bf4599c3baaefeb228)
testsuite: disable gcc's warnings about casts of incompatible prototypes in UNREG

Haskell's 'foreign import' declaraion does not have a way
to extress exact C prototypes (it ignores 'const' modifiers, exact pointer
types, etc.) which leads to warnings when C backend generates calls to such
functions:

    /tmp/ghc32698_0/ghc32698_10.hc:52:5:
         warning: conflicting types for built-in function ‘strlen’ [enabled by default]
         EF_(strlen);
             ^

Patch disables builtin functions for UNREG build
to workaround test failures due to stderr mismatch.

Fixes the following test failures:
    TEST="safePkg01 T5423 T7574 T3736"

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit fcdd58d2ddcfd8d420adbcb3f20c1d666bc834e6)
testsuite: mark testwsdeque mark as faulty on NOSMP builds

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit 2fcb36e41f46f80f75e2f245a1a45457f0f7d6d2)
Use correct precedence when printing contexts with class operators

Fixes Trac #9658

(cherry picked from commit 48089ccf4f1f239b3268b2cb52b8aa0f7356485b)

Conflicts:
	compiler/types/TypeRep.lhs
	testsuite/tests/ghci/scripts/all.T
	testsuite/tests/perf/compiler/T5837.stderr
	testsuite/tests/typecheck/should_fail/ContextStack2.stderr
	testsuite/tests/typecheck/should_fail/T8392a.stderr
Improve comments and tracing in SpecConstr

(cherry picked from commit 675c5478793ac8cede5daca4f70cd09846879837)
Introduce the Call data types

This is just a small refactoring that makes the code a bit clearer,
using a data type instead of a triple.  We get better pretty-printing too.

(cherry picked from commit c0fe1d9e7a9f23d050319c77f3a38264f3aa22f8)
Do not duplicate call information in SpecConstr (Trac #8852)

This long-standing and egregious bug meant that call information was
being gratuitously copied, leading to an exponential blowup in the
number of calls to be examined when function definitions are deeply
nested.  That is what has been causing the blowup in SpecConstr's
running time, not (as I had previously supposed) generating very large code.

See Note [spec_usg includes rhs_usg]

(cherry picked from commit af4bc31c50c873344a2426d4be842f92edf17019)
rnMethodBind: reject pattern synonyms in instance definitions (fixes #9705)

(cherry picked from commit e5ba36080d08791f44e3bed37721f702e242af96)
Add skeleton 7.8.4 release notes

Signed-off-by: Austin Seipp <austin@well-typed.com>
Flesh out release notes.

Signed-off-by: Austin Seipp <austin@well-typed.com>