| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 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 | ||||
| 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 | ||||
| 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 | ||
| use-unbundled-sphinx-rtd-theme | =================================================================== | no | ||||
| newer-llvm | commit 0cc16aaf89d7dc3963764b7193ceac73e4e3329b 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 =================================================================== |
Matthew Pickering <matthewtpickering@gmail.com> | no | 2023-01-30 | ||
| hadrian-plans | 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. =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | no | |||
| hadrian-haddock-opts | Pass 'mathjax' to Haddock Hadrian currently doesn't allow us to modify Haddock options, so patch Hadrian to manually pass the 'mathjax' option. =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | yes | upstream | ||
| hadrian-relpath | 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 =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | no | |||
| hadrian-iserv | Fix installation patch for iserv/unlit =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | yes | upstream | ||
| allow-setting-llvm-program | Allow setting path for LLC/OPT during configuration Patch configure.ac to allow us to modify the path for LLC/OPT during configuration. =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | no | |||
| fix-cross-compilation | commit bd92182cd56140ffb2f68ec01492e5aa6333a8fc 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. =================================================================== |
Ben Gamari <bgamari.foss@gmail.com> | no | 2022-06-21 | ||
| sparc-support | =================================================================== | no | ||||
| hadrian-disable-threaded | =================================================================== | no | ||||
| fix-hs_cmpxchg64 | commit 9fa545722f9151781344446dd5501db38cb90dd1 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. =================================================================== |
Cheng Shao <terrorjack@type.dance> | no | 2023-02-27 | ||
| fix-32-bit-unreg | commit 9194c9c066a31cbb7a49830e4b5e2454fd4af6ba 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) =================================================================== |
Cheng Shao <terrorjack@type.dance> | no | 2023-01-23 | ||
| hadrian-fix-dnosmp | commit bea762f2c9d3ff1f67e3fdb22a8ac288b32225b0 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 =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | no | 2023-10-12 | ||
| hadrian-enable-interpreter | Enable GHCi on all platforms in Debian =================================================================== |
Ilias Tsitsimpis <iliastsi@debian.org> | yes | upstream | ||
| use-modern-atomics | commit f8fa1d08d7cbfef508bab355bda80f495e928f98 ghc-prim: Use C11 atomics Previously `ghc-prim`'s atomic wrappers used the legacy `__sync_*` family of C builtins. Here we refactor these to rather use the appropriate C11 atomic equivalents, allowing us to be more explicit about the expected ordering semantics. =================================================================== |
Ben Gamari <bgamari.foss@gmail.com> | no | 2023-04-17 | ||
| ppc64el-fix-clrri | [PATCH] PPC NCG: Generate clear right insn at arch width The clear right immediate (clrrxi) is only available in word and doubleword width. Generate clrrxi instructions at architecture width for all MachOp widths. Fixes #24145 |
Peter Trommler <ptrommler@acm.org> | no | 2023-11-07 | ||
| dfe1c3540e4b519b62b862b5966dfec5cae9ece1.patch | [PATCH] llvmGen: Align objects in the data section Objects in the data section may be referenced via tagged pointers. Thus, align those objects to a 4- or 8-byte boundary for 32- or 64-bit platforms, respectively. Note, this may need to be reconsidered if objects with a greater natural alignment requirement are emitted as e.g. 128-bit atomics. Fixes #24163. |
Stefan Schulze Frielinghaus <stefansf@linux.ibm.com> | no | 2023-11-27 | ||
| fix-gcc14-ffi_arg | commit 1f534c2e7388273e70534680212c1357614c11ed Fix C output for modern C initiative GCC 14 on aarch64 rejects the C code written by GHC with this kind of error: error: assignment to ‘ffi_arg’ {aka ‘long unsigned int’} from ‘HsPtr’ {aka ‘void *’} makes integer from pointer without a cast [-Wint-conversion] 68 | *(ffi_arg*)resp = cret; | ^ Add the correct cast. For more information on this see: https://fedoraproject.org/wiki/Changes/PortingToModernC Tested-by: Richard W.M. Jones <rjones@redhat.com> =================================================================== |
Florian Weimer <fweimer@redhat.com> | no | 2024-02-15 | ||
| time_t-directory | [PATCH] Use capi for syscalls that break under musl's handling of 64-bit time_t Closes #145. |
Marios Titas <redneb@gmx.com> | no | 2022-10-02 | ||
| time_t-time | [PATCH] Use capi for syscalls that break under musl's handling of 64-bit time_t | Marios Titas <redneb@gmx.com> | no | 2022-10-02 | ||
| time_t-unix | [PATCH] Use capi for syscalls that break under musl's handling of 64-bit time_t | Marios Titas <redneb@gmx.com> | no | 2022-10-02 |