Merge version 8.8.1+dfsg1+is+8.6.5+dfsg1-3+rpi1 and 8.8.3-3 to produce 8.8.3-3+rpi1

Merge ghc (8.8.3-3) import into refs/heads/workingbranch

[PATCH] fixup! Fix endian handling w.r.t. CPP macro WORDS_BIGENDIAN

Gbp-Pq: Name 11f8eef5a9625c77f78a829406c446b615ed6168.patch

[PATCH] Fix endian handling w.r.t. CPP macro WORDS_BIGENDIAN

Include header file `ghcautoconf.h` where the CPP macro
`WORDS_BIGENDIAN` is defined. This finally fixes #17337 (in conjunction
with commit 6c59cc71dc).

Gbp-Pq: Name 3c12355ece0fa14e534c71a9f7327eda9773fad9.patch

Do not define hs_atomic{read,write}64() on non-64bit

Bug: https://gitlab.haskell.org/ghc/ghc/issues/17886
Forwarded: https://gitlab.haskell.org/ghc/ghc/merge_requests/2804

Gbp-Pq: Name fix-32bit-atomic

llvm-targets: Add arm-unknown-linux-gnueabi

Forwarded: https://gitlab.haskell.org/ghc/ghc/merge_requests/2789

Add arm-unknown-linux-gnueabi, which is used by Debian's ARM EABI port
(armel), as an LLVM target.

Gbp-Pq: Name llvm-arm-unknown-linux-gnueabi.patch

Use LLVM 9

Backport commits 8c5cb80698 and 8e5851f070 to use LLVM 9.

Gbp-Pq: Name llvm-9.patch

Allow unregisterised ghc-8.6 to build newer GHC

Commit af9b744bbf1 introduced a regression stopping existing unregisterised
compilers from being able to compile newer versions of GHC. The problem is
that the bootstrap compiler uses the newer `includes/stg/MiscClosures.h` file
where some defines have been renamed, resulting in the following error:
.
 error: ‘stg_atomicModifyMutVarzh’ undeclared (first use in this function); did you mean ‘stg_atomicModifyMutVar2zh’?
.
 For more information, see https://gitlab.haskell.org/ghc/ghc/issues/17111.
.
 This patch can be removed, once ghc-8.6 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/17111

Gbp-Pq: Name fix-build-using-unregisterised-v8.6

local-mathjax

Gbp-Pq: Name local-mathjax

Add kfreebsdgnu to GHC_CONVERT_OS in aclocal.m4

Bug-Debian: https://bugs.debian.org/913140

Gbp-Pq: Name kfreebsd-aclocal.m4

Use the stage1 binaries for install

Last-Update: 2017-01-29

In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.

Gbp-Pq: Name use-stage1-binaries-for-install.patch

Use native x86_64 instructions on x32

This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571

Gbp-Pq: Name x32-use-native-x86_64-insn.patch

buildpath-abi-stability

Forwarded to https://ghc.haskell.org/trac/ghc/ticket/10424

Forwarded to https://ghc.haskell.org/trac/ghc/ticket/10424

Gbp-Pq: Name buildpath-abi-stability.patch

Do not emit a warning if the .haddock file is missing

As it is quite common on Debian installations to install the -dev package
without the -doc package.

Gbp-Pq: Name no-missing-haddock-file-warning

Use VFPv3-D16 FPU for ARM builds

Upstream-Bug: https://ghc.haskell.org/trac/ghc/ticket/5914
Launchpad-Bug: https://ghc.haskell.org/trac/ghc/ticket/5914

Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.

Gbp-Pq: Name ARM-VFPv3D16

use-debian-gen_contents_index

===================================================================

Gbp-Pq: Name use-debian-gen_contents_index

ghc (8.8.3-3) unstable; urgency=medium

  * Reupload due to bad debian/rules merge

[dgit import unpatched ghc 8.8.3-3]

Import ghc_8.8.3-3.debian.tar.xz

[dgit import tarball ghc 8.8.3-3 ghc_8.8.3-3.debian.tar.xz]

Merge version 8.8.1+dfsg1+is+8.6.5+dfsg1-2+rpi1 and 8.8.1+dfsg1+is+8.6.5+dfsg1-3 to produce 8.8.1+dfsg1+is+8.6.5+dfsg1-3+rpi1

Merge ghc (8.8.1+dfsg1+is+8.6.5+dfsg1-3) import into refs/heads/workingbranch

powerpc32: fix 64-bit comparison

On powerpc32 64-bit comparison code generated dangling
target labels. This caused ghc build failure as:
    $ ./configure --target=powerpc-unknown-linux-gnu && make
    ...
    SCCs aren't in reverse dependent order
    bad blockId n3U

 This happened because condIntCode' in PPC codegen generated
 label name but did not place the label into `cmp_lo` code block.

 The change adds the `cmp_lo` label into the case of negative
 comparison.
Signed-off-by: 's avatarSergei Trofimovich <slyfox@gentoo.org>
 .
Origin: https://gitlab.haskell.org/ghc/ghc/commit/25dce3fc05e4788240ac6d192919063a9f548f7f
Last-Update: 2019-08-09

Gbp-Pq: Name powerpc-fix-64-bit-comparision.patch

PprC-Add-support-for-adjacent-floats

commit 35a897782b6b0a252da7fdcf4921198ad4e1d96c
Author: James Clarke <jrtc27@jrtc27.com>
Date:   Thu Nov 22 11:55:17 2018 -0500

    UNREG: PprC: Add support for adjacent floats

    When two 32-bit floats are adjacent for a 64-bit target, there is no
    padding between them to force alignment, so we must combine their bit
    representations into a single word.

    Reviewers: bgamari, simonmar

    Reviewed By: simonmar

    Subscribers: rwbarton, carter

    GHC Trac Issues: #15853

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

Gbp-Pq: Name PprC-Add-support-for-adjacent-floats

cherry-pick of upstream commits

Last-Update: 2019-05-27

beba89a0f16681c85d39fc8a894bde4162ff492a.patch:
5e63a25249f3cb07300258e115af9ff55079d2ea.patch:

Gbp-Pq: Name risc-support.patch

Allow unregisterised ghc-8.4 to build newer GHC

Commit 4075656e8bb introduced a regression stopping existing unregisteristed
compilers from being able to compile newer versions of GHC. The problem is
that the bootstrap compiler uses the newer `rts/storage/ClosureTypes.h` file
where some defines have been renamed, resulting in the following error:
.
  error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’?
.
 For more information, see https://gitlab.haskell.org/ghc/ghc/issues/15913.
.
 This patch can be removed, once ghc-8.4 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/15913
Bug-Debian: https://bugs.debian.org/932941

Gbp-Pq: Name fix-build-using-unregisterized-v8.4

local-mathjax

Gbp-Pq: Name local-mathjax

Add kfreebsdgnu to GHC_CONVERT_OS in aclocal.m4

Bug-Debian: https://bugs.debian.org/913140

Gbp-Pq: Name kfreebsd-aclocal.m4

add_-latomic_to_ghc-prim

commit ce3897ffd6e7c8b8f36b8e920168bac8c7f836ae
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Date:   Tue Sep 18 17:45:17 2018 +0200

    Fix check whether GCC supports __atomic_ builtins

    Summary:
    C11 atomics are never used because:

    * The program used for checking whether GCC supports
    __atomic_ builtins fails with the following error:

    ```
      error: size mismatch in argument 2 of `__atomic_load`
       int test(int *x) { int y; __atomic_load(&x, &y, __ATOMIC_SEQ_CST); return x; }
    ```

    * There is a typo when checking if CONF_GCC_SUPPORTS__ATOMICS equals YES,
    resulting in PRIM_CFLAGS and PRIM_EXTRA_LIBRARIES never being set.

    Reviewers: bgamari

    Reviewed By: bgamari

    Subscribers: rwbarton, erikd, carter

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

Gbp-Pq: Name add_-latomic_to_ghc-prim

fix osReserveHeapMemory block alignment

X-Git-Url: https://git.haskell.org/ghc.git/commitdiff_plain/e175aaf6918bb2b497b83618dc4c270a0d231a1c

fix osReserveHeapMemory block alignment

Before the change osReserveHeapMemory() attempted
to allocate chunks of memory via osTryReserveHeapMemory()
not multiple of MBLOCK_SIZE in the following fallback code:

```
    if (at == NULL) {
        *len -= *len / 8;
```

and caused assertion failure:

```
$ make fulltest TEST=T11607 WAY=threaded1
T11607: internal error: ASSERTION FAILED: file rts/posix/OSMem.c, line 457
    (GHC version 8.7.20180716 for riscv64_unknown_linux)

```

The change applies alignment mask before each MBLOCK allocation attempt
and fixes WAY=threaded1 test failures on qemu-riscv64.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: run 'make fulltest WAY=threaded1'

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Gbp-Pq: Name e175aaf6918bb2b497b83618dc4c270a0d231a1c.patch

driver: skip -Bsymbolic on unregisterised targets

Trac #15338 is yet another example where -Bsymbolic breaks
semantics of a C program: global variable duplication happens
and unsafePerformIO creates two stdout copies.

When -Bsymbolic is not used both C compiler and linker agree
on how global variables are handled. In case of sh4 it consists
on a few assertions:

1. global variable is exported from shared library
2. code is referred to this variable via GOT-like mechanism to allow
   interposition
3. global variable is present .bss section on an executable
   (as an R_*_COPY relocation: symbol contents is copied at executable
   startup time)
4. and symbol in executable interposes symbol in shared library.

This way both code in shared library and code in executable refer
to a copy of global variable in .bss section of an executable.

Unfortunately -Bsymbolic option breaks assumption [2.] and generates
direct references to the symbol. This causes mismatch between
values seen from executable and values seen from shared library code.

This change disables '-Bsymbolic' for unregisterised targets.

Gbp-Pq: Name bsymbolic-only-for-registerised.patch

with new ghc 8.4.3, the armel situation seems to have improved,

apply this patch unconditionally.
===================================================================

Gbp-Pq: Name llvm-arm-unknown-linux-gnueabi.patch

Use the stage1 binaries for install

Last-Update: 2017-01-29

In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.

Gbp-Pq: Name use-stage1-binaries-for-install.patch

Use native x86_64 instructions on x32

This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571

Gbp-Pq: Name x32-use-native-x86_64-insn.patch

buildpath-abi-stability

Forwarded to https://ghc.haskell.org/trac/ghc/ticket/10424

Forwarded to https://ghc.haskell.org/trac/ghc/ticket/10424

Gbp-Pq: Name buildpath-abi-stability.patch

Do not emit a warning if the .haddock file is missing

As it is quite common on Debian installations to install the -dev package
without the -doc package.

Gbp-Pq: Name no-missing-haddock-file-warning

Use VFPv3-D16 FPU for ARM builds

Upstream-Bug: https://ghc.haskell.org/trac/ghc/ticket/5914
Launchpad-Bug: https://ghc.haskell.org/trac/ghc/ticket/5914

Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.

Gbp-Pq: Name ARM-VFPv3D16

use-debian-gen_contents_index

===================================================================

Gbp-Pq: Name use-debian-gen_contents_index

ghc (8.8.1+dfsg1+is+8.6.5+dfsg1-3) unstable; urgency=medium

  * Switch to python3-sphinx; Closes: #943097

[dgit import unpatched ghc 8.8.1+dfsg1+is+8.6.5+dfsg1-3]

Import ghc_8.8.1+dfsg1+is+8.6.5+dfsg1-3.debian.tar.xz

[dgit import tarball ghc 8.8.1+dfsg1+is+8.6.5+dfsg1-3 ghc_8.8.1+dfsg1+is+8.6.5+dfsg1-3.debian.tar.xz]

Import ghc_8.8.3.orig.tar.xz

[dgit import orig ghc_8.8.3.orig.tar.xz]

Merge version 8.4.4+dfsg1-3+rpi1 and 8.8.1+dfsg1+is+8.6.5+dfsg1-2 to produce 8.8.1+dfsg1+is+8.6.5+dfsg1-2+rpi1

Merge ghc (8.8.1+dfsg1+is+8.6.5+dfsg1-2) import into refs/heads/workingbranch

powerpc-fix-64-bit-comparision

    $ ./configure --target=powerpc-unknown-linux-gnu && make
    ...
    SCCs aren't in reverse dependent order
    bad blockId n3U

 This happened because condIntCode' in PPC codegen generated
 label name but did not place the label into `cmp_lo` code block.

 The change adds the `cmp_lo` label into the case of negative
 comparison.
Signed-off-by: 's avatarSergei Trofimovich <slyfox@gentoo.org>
 .
Origin: https://gitlab.haskell.org/ghc/ghc/commit/25dce3fc05e4788240ac6d192919063a9f548f7f
Last-Update: 2019-08-09

Gbp-Pq: Name powerpc-fix-64-bit-comparision.patch

PprC-Add-support-for-adjacent-floats

commit 35a897782b6b0a252da7fdcf4921198ad4e1d96c
Author: James Clarke <jrtc27@jrtc27.com>
Date:   Thu Nov 22 11:55:17 2018 -0500

    UNREG: PprC: Add support for adjacent floats

    When two 32-bit floats are adjacent for a 64-bit target, there is no
    padding between them to force alignment, so we must combine their bit
    representations into a single word.

    Reviewers: bgamari, simonmar

    Reviewed By: simonmar

    Subscribers: rwbarton, carter

    GHC Trac Issues: #15853

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

Gbp-Pq: Name PprC-Add-support-for-adjacent-floats

risc-support

Gbp-Pq: Name risc-support.patch

fix-build-using-unregisterized-v8.4

.
  error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’?
.
 For more information, see https://gitlab.haskell.org/ghc/ghc/issues/15913.
.
 This patch can be removed, once ghc-8.4 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/issues/15913
Bug-Debian: https://bugs.debian.org/932941

Gbp-Pq: Name fix-build-using-unregisterized-v8.4

local-mathjax

Gbp-Pq: Name local-mathjax

kfreebsd-aclocal.m4

Gbp-Pq: Name kfreebsd-aclocal.m4

add_-latomic_to_ghc-prim

commit ce3897ffd6e7c8b8f36b8e920168bac8c7f836ae
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Date:   Tue Sep 18 17:45:17 2018 +0200

    Fix check whether GCC supports __atomic_ builtins

    Summary:
    C11 atomics are never used because:

    * The program used for checking whether GCC supports
    __atomic_ builtins fails with the following error:

    ```
      error: size mismatch in argument 2 of `__atomic_load`
       int test(int *x) { int y; __atomic_load(&x, &y, __ATOMIC_SEQ_CST); return x; }
    ```

    * There is a typo when checking if CONF_GCC_SUPPORTS__ATOMICS equals YES,
    resulting in PRIM_CFLAGS and PRIM_EXTRA_LIBRARIES never being set.

    Reviewers: bgamari

    Reviewed By: bgamari

    Subscribers: rwbarton, erikd, carter

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

Gbp-Pq: Name add_-latomic_to_ghc-prim

fix osReserveHeapMemory block alignment

fix osReserveHeapMemory block alignment

Before the change osReserveHeapMemory() attempted
to allocate chunks of memory via osTryReserveHeapMemory()
not multiple of MBLOCK_SIZE in the following fallback code:

```
    if (at == NULL) {
        *len -= *len / 8;
```

and caused assertion failure:

```
$ make fulltest TEST=T11607 WAY=threaded1
T11607: internal error: ASSERTION FAILED: file rts/posix/OSMem.c, line 457
    (GHC version 8.7.20180716 for riscv64_unknown_linux)

```

The change applies alignment mask before each MBLOCK allocation attempt
and fixes WAY=threaded1 test failures on qemu-riscv64.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: run 'make fulltest WAY=threaded1'

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Gbp-Pq: Name e175aaf6918bb2b497b83618dc4c270a0d231a1c.patch

bsymbolic-only-for-registerised

Gbp-Pq: Name bsymbolic-only-for-registerised.patch

llvm-arm-unknown-linux-gnueabi

===================================================================

Gbp-Pq: Name llvm-arm-unknown-linux-gnueabi.patch

use-stage1-binaries-for-install

Gbp-Pq: Name use-stage1-binaries-for-install.patch

x32-use-native-x86_64-insn

Gbp-Pq: Name x32-use-native-x86_64-insn.patch

buildpath-abi-stability

Forwarded to https://ghc.haskell.org/trac/ghc/ticket/10424

Gbp-Pq: Name buildpath-abi-stability.patch

no-missing-haddock-file-warning

Gbp-Pq: Name no-missing-haddock-file-warning

ARM-VFPv3D16

Gbp-Pq: Name ARM-VFPv3D16

use-debian-gen_contents_index

===================================================================

Gbp-Pq: Name use-debian-gen_contents_index

ghc (8.8.1+dfsg1+is+8.6.5+dfsg1-2) unstable; urgency=medium

  [ John Paul Adrian Glaubitz ]
  * Enable workaround to avoid memory exhaustation on alpha
  [ Gianfranco Costamagna ]
  * Source-only reupload now that the bootstrap has ended

[dgit import unpatched ghc 8.8.1+dfsg1+is+8.6.5+dfsg1-2]

Import ghc_8.8.1+dfsg1+is+8.6.5+dfsg1-2.debian.tar.xz

[dgit import tarball ghc 8.8.1+dfsg1+is+8.6.5+dfsg1-2 ghc_8.8.1+dfsg1+is+8.6.5+dfsg1-2.debian.tar.xz]

Import ghc_8.8.1+dfsg1+is+8.6.5+dfsg1.orig.tar.xz

[dgit import orig ghc_8.8.1+dfsg1+is+8.6.5+dfsg1.orig.tar.xz]

Merge version 8.4.4+dfsg1-2+rpi1 and 8.4.4+dfsg1-3 to produce 8.4.4+dfsg1-3+rpi1

Merge ghc (8.4.4+dfsg1-3) import into refs/heads/workingbranch

fix-build-sphinx

Gbp-Pq: Name fix-build-sphinx.patch

local-mathjax

Gbp-Pq: Name local-mathjax

revert-llvm-fixes

commit 377fe39888b1c711d15c94583ec83680d8ae7bf4
Author: Ben Gamari <ben@smart-cactus.org>
Date:   Tue Oct 30 11:12:46 2018 -0400

    Revert "Multiple fixes / improvements for LLVM backend"

    This reverts commit 73273be476a8cc6c13368660b042b3b0614fd928.

    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.

Gbp-Pq: Name revert-llvm-fixes

kfreebsd-aclocal.m4

Gbp-Pq: Name kfreebsd-aclocal.m4

haddock-out-of-memory

commit 18cb44dfae3f0847447da33c9d7a25d2709d838f
Author: Alec Theriault <alec.theriault@gmail.com>
Date:   Tue Aug 21 16:03:40 2018 -0400

    Explicitly tell 'getNameToInstances' mods to load

    Calculating which modules to load based on the InteractiveContext means
    maintaining a potentially very large GblRdrEnv.

    In Haddock's case, it is much cheaper (from a memory perspective) to
    just keep track of which modules interfaces we want loaded then hand
    these off explicitly to 'getNameToInstancesIndex'.

    Bumps haddock submodule (commit 40eb5aabed0ae)

    Reviewers: alexbiehl, bgamari

    Reviewed By: alexbiehl

    Subscribers: rwbarton, thomie, carter

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

    (cherry picked from commit c971e1193fa44bb507d1806d5bb61768670dc912)

Gbp-Pq: Name haddock-out-of-memory.patch

add_-latomic_to_ghc-prim

commit ec9aacf3eb2975fd302609163aaef429962ecd87
Author: Moritz Angermann <moritz.angermann@gmail.com>
Date:   Thu Feb 8 16:07:07 2018 +0800

    adds -latomic to. ghc-prim

    Reviewers: bgamari, hvr

    Reviewed By: bgamari

    Subscribers: erikd, hvr, rwbarton, thomie, carter

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

    iliastsi: The original patch fails to correctly detect and use C11
    atomics, so I modified it based on https://phabricator.haskell.org/D5154.

Gbp-Pq: Name add_-latomic_to_ghc-prim

fix-build-using-unregisterized-v8.2

.
  error: conflicting types for 'ghc_GhcPrelude_zdtrModule4_bytes'
  note: in definition of macro 'EB_'
  #define EB_(X)    extern const char X[]
  note: previous definition of 'ghc_GhcPrelude_zdtrModule4_bytes' was here
  char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc";
.
 For more information about the problem, see https://phabricator.haskell.org/D4114.
.
 This patch is a rework of https://phabricator.haskell.org/D3741.
 It modifies Stg.h to include the old definitions, if a compiler older than
 8.4 is being used.
.
 This patch can be removed, once ghc-8.2 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://ghc.haskell.org/trac/ghc/ticket/15201

Gbp-Pq: Name fix-build-using-unregisterized-v8.2

risc-support

Gbp-Pq: Name risc-support.patch

fix osReserveHeapMemory block alignment

fix osReserveHeapMemory block alignment

Before the change osReserveHeapMemory() attempted
to allocate chunks of memory via osTryReserveHeapMemory()
not multiple of MBLOCK_SIZE in the following fallback code:

```
    if (at == NULL) {
        *len -= *len / 8;
```

and caused assertion failure:

```
$ make fulltest TEST=T11607 WAY=threaded1
T11607: internal error: ASSERTION FAILED: file rts/posix/OSMem.c, line 457
    (GHC version 8.7.20180716 for riscv64_unknown_linux)

```

The change applies alignment mask before each MBLOCK allocation attempt
and fixes WAY=threaded1 test failures on qemu-riscv64.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: run 'make fulltest WAY=threaded1'

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Gbp-Pq: Name e175aaf6918bb2b497b83618dc4c270a0d231a1c.patch

use-llvm-6.0

Gbp-Pq: Name use-llvm-6.0.patch

bsymbolic-only-for-registerised

Gbp-Pq: Name bsymbolic-only-for-registerised.patch

llvm-arm-unknown-linux-gnueabi

===================================================================

Gbp-Pq: Name llvm-arm-unknown-linux-gnueabi.patch

use-stage1-binaries-for-install

Gbp-Pq: Name use-stage1-binaries-for-install.patch

x32-use-native-x86_64-insn

Gbp-Pq: Name x32-use-native-x86_64-insn.patch

buildpath-abi-stability

Forwarded to https://ghc.haskell.org/trac/ghc/ticket/10424

Gbp-Pq: Name buildpath-abi-stability.patch

hurd

Provided by “Pino” via Samuel Thibault. Not yet pushed upstream.

Gbp-Pq: Name hurd.diff

no-missing-haddock-file-warning

Gbp-Pq: Name no-missing-haddock-file-warning

ARM-VFPv3D16

Gbp-Pq: Name ARM-VFPv3D16

use-debian-gen_contents_index

===================================================================

Gbp-Pq: Name use-debian-gen_contents_index

ghc (8.4.4+dfsg1-3) unstable; urgency=medium

  * Use the ARM7TDMI core on armel (Closes: #915333)

[dgit import unpatched ghc 8.4.4+dfsg1-3]

Import ghc_8.4.4+dfsg1-3.debian.tar.xz

[dgit import tarball ghc 8.4.4+dfsg1-3 ghc_8.4.4+dfsg1-3.debian.tar.xz]

Merge version 8.4.4+dfsg1-1+rpi1 and 8.4.4+dfsg1-2 to produce 8.4.4+dfsg1-2+rpi1

Merge ghc (8.4.4+dfsg1-2) import into refs/heads/workingbranch

fix-build-sphinx

Gbp-Pq: Name fix-build-sphinx.patch

local-mathjax

Gbp-Pq: Name local-mathjax

revert-llvm-fixes

commit 377fe39888b1c711d15c94583ec83680d8ae7bf4
Author: Ben Gamari <ben@smart-cactus.org>
Date:   Tue Oct 30 11:12:46 2018 -0400

    Revert "Multiple fixes / improvements for LLVM backend"

    This reverts commit 73273be476a8cc6c13368660b042b3b0614fd928.

    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.

Gbp-Pq: Name revert-llvm-fixes

kfreebsd-aclocal.m4

Gbp-Pq: Name kfreebsd-aclocal.m4

haddock-out-of-memory

commit 18cb44dfae3f0847447da33c9d7a25d2709d838f
Author: Alec Theriault <alec.theriault@gmail.com>
Date:   Tue Aug 21 16:03:40 2018 -0400

    Explicitly tell 'getNameToInstances' mods to load

    Calculating which modules to load based on the InteractiveContext means
    maintaining a potentially very large GblRdrEnv.

    In Haddock's case, it is much cheaper (from a memory perspective) to
    just keep track of which modules interfaces we want loaded then hand
    these off explicitly to 'getNameToInstancesIndex'.

    Bumps haddock submodule (commit 40eb5aabed0ae)

    Reviewers: alexbiehl, bgamari

    Reviewed By: alexbiehl

    Subscribers: rwbarton, thomie, carter

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

    (cherry picked from commit c971e1193fa44bb507d1806d5bb61768670dc912)

Gbp-Pq: Name haddock-out-of-memory.patch

add_-latomic_to_ghc-prim

commit ec9aacf3eb2975fd302609163aaef429962ecd87
Author: Moritz Angermann <moritz.angermann@gmail.com>
Date:   Thu Feb 8 16:07:07 2018 +0800

    adds -latomic to. ghc-prim

    Reviewers: bgamari, hvr

    Reviewed By: bgamari

    Subscribers: erikd, hvr, rwbarton, thomie, carter

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

    iliastsi: The original patch fails to correctly detect and use C11
    atomics, so I modified it based on https://phabricator.haskell.org/D5154.

Gbp-Pq: Name add_-latomic_to_ghc-prim

fix-build-using-unregisterized-v8.2

.
  error: conflicting types for 'ghc_GhcPrelude_zdtrModule4_bytes'
  note: in definition of macro 'EB_'
  #define EB_(X)    extern const char X[]
  note: previous definition of 'ghc_GhcPrelude_zdtrModule4_bytes' was here
  char ghc_GhcPrelude_zdtrModule4_bytes[] = "ghc";
.
 For more information about the problem, see https://phabricator.haskell.org/D4114.
.
 This patch is a rework of https://phabricator.haskell.org/D3741.
 It modifies Stg.h to include the old definitions, if a compiler older than
 8.4 is being used.
.
 This patch can be removed, once ghc-8.2 is no longer the bootstrap compiler.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://ghc.haskell.org/trac/ghc/ticket/15201

Gbp-Pq: Name fix-build-using-unregisterized-v8.2

risc-support

Gbp-Pq: Name risc-support.patch

fix osReserveHeapMemory block alignment

fix osReserveHeapMemory block alignment

Before the change osReserveHeapMemory() attempted
to allocate chunks of memory via osTryReserveHeapMemory()
not multiple of MBLOCK_SIZE in the following fallback code:

```
    if (at == NULL) {
        *len -= *len / 8;
```

and caused assertion failure:

```
$ make fulltest TEST=T11607 WAY=threaded1
T11607: internal error: ASSERTION FAILED: file rts/posix/OSMem.c, line 457
    (GHC version 8.7.20180716 for riscv64_unknown_linux)

```

The change applies alignment mask before each MBLOCK allocation attempt
and fixes WAY=threaded1 test failures on qemu-riscv64.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Test Plan: run 'make fulltest WAY=threaded1'

Reviewers: simonmar, bgamari, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

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

Gbp-Pq: Name e175aaf6918bb2b497b83618dc4c270a0d231a1c.patch

use-llvm-6.0

Gbp-Pq: Name use-llvm-6.0.patch

bsymbolic-only-for-registerised

Gbp-Pq: Name bsymbolic-only-for-registerised.patch

llvm-arm-unknown-linux-gnueabi

===================================================================

Gbp-Pq: Name llvm-arm-unknown-linux-gnueabi.patch

use-stage1-binaries-for-install

Gbp-Pq: Name use-stage1-binaries-for-install.patch

x32-use-native-x86_64-insn

Gbp-Pq: Name x32-use-native-x86_64-insn.patch

buildpath-abi-stability

Forwarded to https://ghc.haskell.org/trac/ghc/ticket/10424

Gbp-Pq: Name buildpath-abi-stability.patch