| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| use-debian-gen_contents_index | =================================================================== | no | ||||
| ARM-VFPv3D16 | Use VFPv3-D16 FPU for ARM builds 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. =================================================================== |
Jani Monoses <jani@ubuntu.com> | no | |||
| no-missing-haddock-file-warning | 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. =================================================================== |
Joachim Breitner <nomeata@debian.org> | no | |||
| buildpath-abi-stability.patch | Forwarded to https://ghc.haskell.org/trac/ghc/ticket/10424 =================================================================== |
no | ||||
| buildpath-abi-stability-2.patch | Don't include BufPos in interface files=================================================================== | Matthew Pickering | yes | upstream | https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8972 | |
| x32-use-native-x86_64-insn.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 . =================================================================== |
no | ||||
| use-stage1-binaries-for-install.patch | Use the stage1 binaries for install 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. . =================================================================== |
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> | no | 2017-01-29 | ||
| kfreebsd-aclocal.m4 | Add kfreebsdgnu to GHC_CONVERT_OS in aclocal.m4 =================================================================== |
Svante Signell <svante.signell@gmail.com> | no | debian | ||
| local-mathjax | =================================================================== | no | ||||
| haddock-remove-googleapis-fonts | Remove hard-coded googleapis font URL =================================================================== |
yes | debian upstream | |||
| fix-llvm-armel | 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. =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | yes | upstream | ||
| latomic-subword | commit 90f06a0e015e18c066fe1569fb2add318bec72ca Check for libatomic dependency for atomic operations Some platforms (e.g. RISC-V) require linking against libatomic for some (e.g. sub-word-sized) atomic operations. Fixes #19119. =================================================================== |
Haochen Tong <i@hexchain.org> | no | 2021-10-11 | ||
| latomic-64bit | Use libatomic for 64-bit operations The rts package uses GCC's __atomic built-in functions on 64-bit values. This is not supported on some 32bit platforms (e.g., mipsel) resulting in the following compilation error: rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_load_8' rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_store_8' rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_fetch_add_8' Fix this by linking against libatomic. =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | yes | upstream | ||
| 78db231ffdf8385662812781c1d09c630cfad313.patch | [PATCH] configure: bump LlvmMaxVersion to 14 LLVM 13.0.0 is released in Oct 2021, and latest head validates against LLVM 13 just fine if LlvmMaxVersion is bumped. |
Cheng Shao <astrohavoc@gmail.com> | no | 2022-01-27 | ||
| ddd2591c5ca395e39ea36855e5b7e0a3464b7ad8.patch | [PATCH] Update supported LLVM versions Pull forward minimum version to match 9.2. (cherry picked from commit c26faa54c5fbe902ccb74e79d87e3fa705e270d1) |
Ben Gamari <ben@smart-cactus.org> | no | 2022-04-29 | ||
| separate-docs | =================================================================== | no |