hadrian-fix-dnosmp

commit bea762f2c9d3ff1f67e3fdb22a8ac288b32225b0
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Date:   Thu Oct 12 12:44:02 2023 +0300

    hadrian: Pass -DNOSMP to C compiler when needed

    Hadrian passes the -DNOSMP flag to GHC when the target doesn't support
    SMP, but doesn't pass it to CC as well, leading to the following
    compilation error on mips64el:

    | Run Cc (FindCDependencies CDep) Stage1: rts/sm/NonMovingScav.c => _build/stage1/rts/build/c/sm/NonMovingScav.o.d
    Command line: /usr/bin/mips64el-linux-gnuabi64-gcc -E -MM -MG -MF _build/stage1/rts/build/c/hooks/FlagDefaults.thr_debug_p_o.d -MT _build/stage1/rts/build/c/hooks/FlagDefaults.o -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -Irts/include -x c rts/hooks/FlagDefaults.c -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn -Wnested-externs -Wredundant-decls -Wundef -fno-strict-aliasing -DTHREADED_RTS -DDEBUG -fomit-frame-pointer -O2 -g -Irts -I_build/stage1/rts/build -DDEBUG -fno-omit-frame-pointer -g3 -O0
    ===> Command failed with error code: 1
    In file included from rts/include/Stg.h:348,
                     from rts/include/Rts.h:38,
                     from rts/hooks/FlagDefaults.c:8:
    rts/include/stg/SMP.h:416:2: error: #error memory barriers unimplemented on this architecture
      416 | #error memory barriers unimplemented on this architecture
          |  ^~~~~
    rts/include/stg/SMP.h:440:2: error: #error memory barriers unimplemented on this architecture
      440 | #error memory barriers unimplemented on this architecture
          |  ^~~~~
    rts/include/stg/SMP.h:464:2: error: #error memory barriers unimplemented on this architecture
      464 | #error memory barriers unimplemented on this architecture
          |  ^~~~~

    The old make system correctly passed this flag to both GHC and CC [1].

    Fix this error by passing -DNOSMP to CC as well.

    [1] https://gitlab.haskell.org/ghc/ghc/-/blob/00920f176b0235d5bb52a8e054d89a664f8938fe/rts/ghc.mk#L407

    Closes #24082

Gbp-Pq: Name hadrian-fix-dnosmp

fix-32-bit-unreg

commit 9194c9c066a31cbb7a49830e4b5e2454fd4af6ba
Author: Cheng Shao <terrorjack@type.dance>
Date:   Mon Jan 23 13:17:07 2023 +0000

    CmmToC: fix CmmRegOff for 64-bit register on a 32-bit target

    We used to print the offset value to a platform word sized integer.
    This is incorrect when the offset is negative (e.g. output of cmm
    constant folding) and the register is 64-bit but on a 32-bit target,
    and may lead to incorrect runtime result (e.g. #22607).

    The fix is simple: just treat it as a proper MO_Add, with the correct
    width info inferred from the register itself.

    Metric Increase:
        T12707
        T13379
        T4801
        T5321FD
        T5321Fun

    (cherry picked from commit d151546e59a50158f25c3df6728b00d3c27bb4b9)

Gbp-Pq: Name fix-32-bit-unreg

fix-hs_cmpxchg64

commit 9fa545722f9151781344446dd5501db38cb90dd1
Author: Cheng Shao <terrorjack@type.dance>
Date:   Mon Feb 27 19:11:27 2023 +0000

    ghc-prim: fix hs_cmpxchg64 function prototype

    hs_cmpxchg64 must return a StgWord64, otherwise incorrect runtime
    results of 64-bit MO_Cmpxchg will appear in 32-bit unregisterised
    builds, which go unnoticed at compile-time due to C implicit casting
    in .hc files.

Gbp-Pq: Name fix-hs_cmpxchg64

hadrian-disable-threaded

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

Gbp-Pq: Name hadrian-disable-threaded

sparc-support

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

Gbp-Pq: Name sparc-support

fix-cross-compilation

commit bd92182cd56140ffb2f68ec01492e5aa6333a8fc
Author: Ben Gamari <bgamari.foss@gmail.com>
Date:   Tue Jun 21 14:05:59 2022 +0000

    configure: Use AC_PATH_TOOL to detect tools

    Previously we used AC_PATH_PROG which, as noted by #21601, does not
    look for tools with a target prefix,
    breaking cross-compilation.

    Fixes #21601.

Gbp-Pq: Name fix-cross-compilation

Allow setting path for LLC/OPT during configuration

Patch configure.ac to allow us to modify the path for LLC/OPT during
configuration.

Gbp-Pq: Name allow-setting-llvm-program

Fix installation patch for iserv/unlit

Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/22557
Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/22697

Gbp-Pq: Name hadrian-iserv

Use realpath instead of custom script

Use realpath instead of the custom script, which is broken. As an example,

  $ ./mk/relpath.sh /usr/lib/ghc/lib /usr/lib/ghc-doc
  ..-doc
  $ realpath --relative-to=/usr/lib/ghc/lib /usr/lib/ghc-doc
  ../../ghc-doc

Gbp-Pq: Name hadrian-relpath

Pass 'mathjax' to Haddock

Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/23625

Hadrian currently doesn't allow us to modify Haddock options, so
patch Hadrian to manually pass the 'mathjax' option.

Gbp-Pq: Name hadrian-haddock-opts

Add more hadrian bootstrap plans

Hadrian only contains bootstrap plans for previous GHC versions. Add plans for
the current version as well, since we may want to bootstrap hadrian with a
cross-compiled GHC that is of the same version as the GHC we are building here.

Gbp-Pq: Name hadrian-plans

newer-llvm

commit 0cc16aaf89d7dc3963764b7193ceac73e4e3329b
Author: Matthew Pickering <matthewtpickering@gmail.com>
Date:   Mon Jan 30 10:58:12 2023 +0000

    Bump supported LLVM range from 10 through 15 to 11 through 16

    LLVM 15 turns on the new pass manager by default, which we have yet to
    migrate to so for new we pass the `-enable-new-pm-0` flag in our
    llvm-passes flag.

    LLVM 11 was the first version to support the `-enable-new-pm` flag so we
    bump the lowest supported version to 11.

    Our CI jobs are using LLVM 12 so they should continue to work despite
    this bump to the lower bound.

    Fixes #21936

Gbp-Pq: Name newer-llvm

use-unbundled-sphinx-rtd-theme

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

Gbp-Pq: Name use-unbundled-sphinx-rtd-theme

Fix LLVM error on armel

GHC 8.10 fails to build on armel with the following error:
   LLVM ERROR: unable to allocate function argument #8
   PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
   Stack dump:
   0.  Program arguments: llc-12 -O2 -enable-tbaa -relocation-model=pic -mcpu=arm7tdmi -mattr=+soft-float,-vfp2,-vfp2sp,-vfp3,-vfp3d16,-vfp3d16sp,-vfp3sp,-fp16,-vfp4,-vfp4d16,-vfp4d16sp,-vfp4sp,-fp-armv8,-fp-armv8d16,-fp-armv8d16sp,-fp-armv8sp,-fullfp16,-fp64,-d32,-neon,-crypto,-dotprod,-fp16fml,-bf16,-mve,-mve.fp,-fpregs,+strict-align /tmp/ghc5537_0/ghc_6.bc -o /tmp/ghc5537_0/ghc_7.lm_s
   1.  Running pass 'Function Pass Manager' on module '/tmp/ghc20177_0/ghc_6.bc'.
   2.  Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
   `llc-12' failed in phase `LLVM Compiler'. (Exit code: -6)
   make[3]: *** [rts/ghc.mk:325: rts/dist/build/HeapStackCheck.o] Error 1

 Surprisingly, reverting commit 4540bbe2811e860f35de6e67ab2f0040592fd3a5 fixes
 thie error.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/20285

Gbp-Pq: Name fix-llvm-armel

Remove hard-coded googleapis font URL

Bug: https://github.com/haskell/haddock/issues/1211
Bug-Debian: https://bugs.debian.org/963690

Gbp-Pq: Name haddock-remove-googleapis-fonts

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 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

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

ghc (9.4.7-3) unstable; urgency=medium

  * debian/patches/dfe1c3540e4b519b62b862b5966dfec5cae9ece1.patch:
    - cherry-pick upstream fix for misaligned objects in the data section with
      llvm-based builds. (LP: #2052696)

[dgit import unpatched ghc 9.4.7-3]

Import ghc_9.4.7-3.debian.tar.xz

[dgit import tarball ghc 9.4.7-3 ghc_9.4.7-3.debian.tar.xz]

Import ghc_9.4.7.orig.tar.xz

[dgit import orig ghc_9.4.7.orig.tar.xz]