-fast-llvm (we add this programmatically to all .cabal files in order to get LTO working properly with shims; just check in this one as an example)

`StgReturn` and `StgRun` defined with inline ASM are not making it into archive
built from `StgCRun.thr_o`, which is an LLVM bitcode LTO object.

(see commented .ll file)

After getting most of way through a build, did:

- used `llc` to compile `rts/dist/build/StgCRun.thr_o` and inspected assembly file
- copy-pasted code into textual IR (from `llvm-dis`) and removed wrapper function
   https://releases.llvm.org/6.0.0/docs/LangRef.html#moduleasm
- convert back into bitcode IR using `llvm-as rts/dist/build/StgCRun.thr_o.ll`
- re-run the `ar` command

It took a lot of other tweaking and trial and error to complete a build
though, so it's likely the state of repo here won't actually complete
successfully.

TODO for moar-LTO:
- bypass mangler with -fast-llvm (which for some reason seems not to
break things..?)
- shim `llc` to be a simple `cp`
- add flags to clang shim :  -O2 -mrelocation-model=static -msse -msse2

This will hopefully allow cross-module optimization of fllvm haskell,
e.g. more of our `libraries/*`

another hack. YOu might have to fix things up after doing boot

Very rough and hacky, with some hacks unnecessary but which I haven't
taken the time to sort out yet.

you need to make sure you have the lto plugin set up correctly, e.g.:

  $ cd /usr/lib/bfd-plugins/
  $ sudo ln -s /usr/lib/gcc/x86_64-linux-gnu/6/liblto_plugin.so .

then do:

   $ export PATH=SHIMS_PATH:$PATH
   $ LD=gold  CC_STAGE0=gcc CC=gcc ./configure
   $ make

You should adjust your path in the same way when building with this GHC,
and you can do e.g.

  $ cabal new-build --disable-profiling --disable-library-profiling --with-compiler=your-ghc-source-tree/inplace/bin/ghc-stage2 --package-db=your-ghc-source-tree/inplace/lib/package.conf.d all

You can see `-time` log in gcc shim file, play with recompilation
options there.

Fixes #16023.

(cherry picked from commit e709c8f8)

Test Plan: Do full build on Windows.

Reviewers: AndreasK, Phyx

Reviewed By: AndreasK

Subscribers: rwbarton, erikd, carter

GHC Trac Issues: #15934

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

(cherry picked from commit 1ef90f99)

Summary:
This fixes a corner case in which we have seen the symbol multiple times in
different static libraries, but due to a depencency we end up loading the
symbol from a library other than the first one.

Previously the runtime linker would only track symbols from the first
library and did not store the full link map.  In this case it was unable
to find the address for the symbols in the second library during delay
loading.

This change stores the address of all symbols seen so a full link map
is generated, such that when we make a different decision later than what
was expected we're able to still correctly load the library.

Test Plan: ./validate, new testcase T15894

Reviewers: angerman, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15894

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

(cherry picked from commit a8b7cef4)

This fixes #15866, the original fix for which didn't merge cleanly to
the stable branch.

Retainer profiling contained a recursion that under
certain circumstances could lead to the stack overflow
in C code.

The idea of the improvement is to keep an explicit stack for the
object, more precise to reuse existing stack, but allow new type of
objects to be stored there.

There is no reliable reproducer that is not a big program
but in some cases foldr (+) 0 [1..10000000] can work.

Reviewers: bgamari, simonmar, erikd, osa1

Reviewed By: bgamari, osa1

Subscribers: osa1, rwbarton, carter

GHC Trac Issues: #14758

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

(cherry picked from commit 5f1d949a)

We thought that visible dependent quantification was impossible
in terms, but Iceland Jack discovered otherwise in #15859. This fixes an
ASSERT failure that arose.

test case: dependent/should_fail/T15859

(cherry picked from commit 72b82343)

(cherry picked from commit 5693ddd0)

As discussed in #15715, the POSIX specification specifies that
attempting to open a FIFO in write-only mode when the FIFO has no
readers will fail with -ENOENT.

[skip ci]

Test Plan: Read it

Reviewers: hvr

Subscribers: rwbarton, carter

GHC Trac Issues: #15715

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

(cherry picked from commit 4ba3fa31)

This reverts commit cbde2726.

Fixes #15105

(cherry picked from commit 25489085)

Eliminates a bit of repetition.

(cherry picked from commit b2f6f896)

(cherry picked from commit 9e0a23b9)

Fixes #15404.

(cherry picked from commit 3584bd42)

Summary:
The logic in `Note [recursive SRTs]` was correct. However, my
implementation of it wasn't: I got the associativity of
`Set.difference` wrong, which led to an extremely subtle and difficult
to find bug.

Fortunately now we have a test case. I was able to cut down the code
to something manageable, and I've added it to the test suite.

Test Plan:
Before (using my stage 1 compiler without the fix):

```
====> T15892(normal) 1 of 1 [0, 0, 0]
cd "T15892.run" &&  "/home/smarlow/ghc/inplace/bin/ghc-stage1" -o T15892
T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output  -O
cd "T15892.run" && ./T15892  +RTS -G1 -A32k -RTS
Wrong exit code for T15892(normal)(expected 0 , actual 134 )
Stderr ( T15892 ):
T15892: internal error: evacuate: strange closure type 0
    (GHC version 8.7.20181113 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
*** unexpected failure for T15892(normal)
=====> T15892(g1) 1 of 1 [0, 1, 0]
cd "T15892.run" &&  "/home/smarlow/ghc/inplace/bin/ghc-stage1" -o T15892
T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output  -O
cd "T15892.run" && ./T15892 +RTS -G1 -RTS +RTS -G1 -A32k -RTS
Wrong exit code for T15892(g1)(expected 0 , actual 134 )
Stderr ( T15892 ):
T15892: internal error: evacuate: strange closure type 0
    (GHC version 8.7.20181113 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```

After (using my stage 2 compiler with the fix):

```
=====> T15892(normal) 1 of 1 [0, 0, 0]
cd "T15892.run" &&  "/home/smarlow/ghc/inplace/test   spaces/ghc-stage2"
-o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output
cd "T15892.run" && ./T15892  +RTS -G1 -A32k -RTS
=====> T15892(g1) 1 of 1 [0, 0, 0]
cd "T15892.run" &&  "/home/smarlow/ghc/inplace/test   spaces/ghc-stage2"
-o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
-fno-warn-missed-specialisations -fshow-warning-groups
-fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat
-dno-debug-output
cd "T15892.run" && ./T15892 +RTS -G1 -RTS +RTS -G1 -A32k -RTS
```

Reviewers: bgamari, osa1, erikd

Reviewed By: osa1

Subscribers: rwbarton, carter

GHC Trac Issues: #15892

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

Reviewers: bgamari, tdammers

Reviewed By: tdammers

Subscribers: monoidal, rwbarton, carter

GHC Trac Issues: #15633

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

(cherry picked from commit 599eaada)

Previously we should just blinding dereference a NULL pointer.

(cherry picked from commit 86f6890e)

We now generally use split-sections instead.

(cherry picked from commit f5fbecc8)

See #15906 for the problem. To fix we simply call `allocate()` instead of
`ALLOC_PRIM()`. `allocate()` does not trigger GC when the nursery is full,
instead it extends it.

Test Plan:
This validates. memo001 now passes with `-debug` compile parameter. I'll add
another test that runs memo001 with `-debug` once I figure out how to use
stdout files for multiple tests.

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, carter

GHC Trac Issues: #15906

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

(cherry picked from commit 691aa715)

This fixes #15875.

Previously the version number was set by hand. This seems like
unnecessary busywork for what is mostly an internal library.

newFamInst lints its types. This is good. But it's not so good
when there have been errors and thus recovery tycons are about.
So we now don't.

Fixes #15796.

Test case: typecheck/should_fail/T15796

(cherry picked from commit 1f72a1c8)

In type-incorrect code, we can sometimes let a coercion
hole make it through the zonker. If this coercion hole then
ends up in the environment (e.g., in the type of a data
constructor), then it causes trouble later.

This patch avoids trouble by substituting the coercion hole
for its representative CoVar. Really, any coercion would do,
but the CoVar was very handy.

test case: polykinds/T15787

(cherry picked from commit 4427315a)

An unfortunate consequence of commit
b9483981 (`Remove HsEqTy and XEqTy`)
is infix uses of `~` in TH quotes now desugar differently than
before. In particular, we have that:

```haskell
a ~ (Int -> Int)
```

Now desugars to:

```haskell
HsOpTy a (~) (HsOpTy Int (->) Int)
```

Which GHC interprets as being:

```haskell
a ~ Int -> Int
```

Or, equivalently:

```haskell
(a ~ Int) -> Int
```

Which is different than what was intended! This is the cause
of #15815.

All of this has revealed that we likely need to renovate the way we
desugar infix type operators to be more consistent with the treatment
for infix expressions (see
https://ghc.haskell.org/trac/ghc/ticket/15815#comment:5 for more on
this.) Doing so would constitute a breaking change, however, so we
will likely want to wait until another major GHC release to do this.

In the meantime, this patch offers a non-invasive change to the way
that infix uses of `~` are desugared. This makes the program
in #15815 compile again by inserting extra `HsParTy`s around the
arguments to `~` if they are lacking them.

Test Plan: make test TEST=T15815

Reviewers: int-index, goldfire, bgamari

Reviewed By: int-index

Subscribers: int-e, rwbarton, carter

GHC Trac Issues: #15815

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

(cherry picked from commit b8a797ec)

This reverts commit 73273be4.

Unfortunately we were unable to come to a fix that didn't sacrifice the
ability to bootstrap GHC using the LLVM backend. Reverting for 8.6.2.

This reverts commit 2e23e1c7.

We suppress some Given errors; see Note [Given errors]
in TcErrors.  But we must be careful not to suppress
Wanted errors because of the presence of these Given
errors -- else we might allow compilation to bogusly
proceed

The rubber hits the road in TcRnTypes.insolubleCt,
where we don't want to treat Givens as insoluble,
nor (and this is the new bit) Deriveds that arise
from Givens.  See Note [Given insolubles] in TcRnTypes.

This fixes #15767.

(cherry picked from commit 6b1102e2)

Ben notes:

  I have folded some test output changes in `TEST="T12529 T12921 mc13
  mc14"` into this patch that were not in the original.

Summary:
This patch fixes #15805, where we found that
`TcType.anyRewritableTyVar` has one wrong case.

Besides the fix, it also:
- removed some unnecessary `ASSERT2(tcIsTcTyVar...)` in `TcType`, as now we have
     `tcIsTcTyVar = isTyVar`.
- fixed some comments

Test Plan: ./validate

Reviewers: goldfire, simonpj, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, carter

GHC Trac Issues: #15805

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

(cherry picked from commit a7f64c6c)