RELEASE=NO

Signed-off-by: Austin Seipp <austin@well-typed.com>
Avoid deadlock in freeTask (called by forkProcess)

Summary: Documented in more detail inline with the change.

Test Plan: validate

Reviewers: austin, simonmar, duncan

Reviewed By: austin, simonmar, duncan

Subscribers: simonmar, relrod, carter

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

(cherry picked from commit 39630ab15cc0607103dc4ef3d9089de44ef17c2d)
Acquire all_tasks_mutex in forkProcess

Summary: (for the same reason that we acquire all the other mutexes)

Test Plan: validate

Reviewers: simonmar, austin, duncan

Reviewed By: simonmar, austin, duncan

Subscribers: simonmar, relrod, carter

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

(cherry picked from commit 16403f0d182d2d3d0b1fbe5ad778ead4bfcb7e16)
Allow multiple entry points when allocating recursive groups (#9303)

Summary:
In this example we ended up with some code that was only reachable via
an info table, because a branch had been optimised away by the native
code generator.  The register allocator then got confused because it
was only considering the first block of the proc to be an entry point,
when actually any of the info tables are entry points.

Test Plan: validate

Reviewers: simonpj, austin

Subscribers: simonmar, relrod, carter

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

(cherry picked from commit da70f9ef49a545707dc32db9662441b9c8845fba)
A panic in CmmBuildInfoTables.bundle shouldn't be a panic (#9329)

Summary:
This code needs more comments, but I believe this is safe.  By
definition I can't have broken anything that was working by turning a
panic into a non-panic anyway.

Test Plan: validate

Reviewers: hvr, simonpj, austin

Subscribers: simonmar, relrod, ezyang, carter

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

GHC Trac Issues: #9329

(cherry picked from commit 2989ffdcb88ab24e8a4e8b3d0454497a0db2652c)
interruptible() was not returning true for BlockedOnSTM (#9379)

Summary:
There's an knock-on fix in HeapStackCheck.c which is potentially
scary, but I'm pretty confident is OK.  See comment for details.

Test Plan:
I've run all the STM
tests I can find, including libraries/stm/tests/stm049 with +RTS -N8
and some of the constants bumped to make it more of a stress test.

Reviewers: hvr, rwbarton, austin

Subscribers: simonmar, relrod, ezyang, carter

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

GHC Trac Issues: #9379

(cherry picked from commit 9d9a55469719908bbd5cd3277e0ac79c0588dc55)
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