| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 19-clang_debian_version.patch | =================================================================== | no | ||||
| 0003-Debian-version-info-and-bugreport.patch | no | |||||
| clang-format-version.diff | no | |||||
| clang-analyzer-force-version.diff | # Force the version of clang in the analyzer # This was causing the static analyzer to fail silently if the clang & clang++ are # not installed =================================================================== |
no | ||||
| 23-strlcpy_strlcat_warning_removed.diff | no | |||||
| declare_clear_cache.diff | no | |||||
| unwind-chain-inclusion.diff | # Without this patch, the first local include of unwind.h might, with the # __has_include_next, try to include the one from the system. # It might be /usr/include/clang/3.4/include/unwind.h # Because of the #ifndef __CLANG_UNWIND_H, it might never include any declaration # from the system. |
no | ||||
| atomic_library_1.diff | no | |||||
| python-clangpath.diff | no | |||||
| fix-clang-path-and-build.diff | =================================================================== | no | ||||
| 0048-Set-html_static_path-_static-everywhere.patch | Set html_static_path = ['_static'] everywhere. | Nicholas D Steeves <nsteeves@gmail.com> | no | 2018-02-10 | ||
| symbolizer-path.diff | =================================================================== | no | ||||
| clang-tidy-run-bin.diff | =================================================================== | no | ||||
| 0001-tools-clang-cmake-resolve-symlinks-in-ClangConfig.cmake.patch | [PATCH] [clang] cmake: resolve symlinks in ClangConfig.cmake Ensure that symlinks such as /usr/lib/cmake/clang-X.Y (pointing to /usr/lib/llvm-X.Y/lib/cmake/llvm) are resolved. This ensures that CLANG_INSTALL_PREFIX ends up to be /usr/lib/llvm-X.Y instead of /usr. Partially addresses PR37128 |
Peter Wu <peter@lekensteyn.nl> | no | 2018-05-04 | ||
| debug-jit-path.diff | =================================================================== | no | ||||
| do-not-fail-on-unexpected-pass.diff | =================================================================== | no | ||||
| disable-display-PASS-UNSUPPORTED-XFAIL.diff | =================================================================== | no | ||||
| fix-llvm-config-obj-src-root.patch | no | |||||
| 0001-llvm-cmake-resolve-symlinks-in-LLVMConfig.cmake.patch | [PATCH] [llvm] cmake: resolve symlinks in LLVMConfig.cmake Ensure that symlinks such as /usr/lib/llvm-X.Y/cmake (pointing to lib/cmake/llvm) are resolved. This ensures that LLVM_INSTALL_PREFIX becomes /usr/lib/llvm-X.Y instead of /usr. Partially addresses PR37128 |
Peter Wu <peter@lekensteyn.nl> | no | 2018-05-04 | ||
| 0044-soname.diff | no | |||||
| lldb-soname.diff | no | |||||
| lldb-libname.diff | no | |||||
| openmp-soname.diff | =================================================================== | no | ||||
| hurd/impl-path-hurd.diff | =================================================================== | no | ||||
| silent-gold-test.diff | fails on debian unstable amd64 Command Output (stderr): -- /build/llvm-toolchain-snapshot-4.0~svn279916/llvm/test/tools/gold/X86/start-lib-common.ll:22:10: error: expected string not found in input ; CHECK: @x = common global i32 0, align 8 ^ <stdin>:1:1: note: scanning from here ; ModuleID = '/build/llvm-toolchain-snapshot-4.0~svn279916/build-llvm/llvm/test/tools/gold/X86/Output/start-lib-common.ll.tmp3.o' ^ <stdin>:4:1: note: possible intended match here @x = common global i32 0, align 4 ^ =================================================================== |
no | ||||
| silent-more-tests.diff | # Comment the tests for the code coverage (fails otherwise) | no | ||||
| silent-MCJIIT-tests.diff | no | |||||
| silent-gold-utils.diff | no | |||||
| silent-test-failing-codeverage.diff | =================================================================== | no | ||||
| silent-amd-tet.diff | =================================================================== | no | ||||
| silent-test-macho.diff | =================================================================== | no | ||||
| silent-llvm-isel-fuzzer.diff | =================================================================== | no | ||||
| remove-test-freezing.diff | =================================================================== | no | ||||
| disable-llvm-symbolizer-test.diff | Silent a test failing on yakkety amd64 /tmp/buildd/llvm-toolchain-snapshot-4.0~svn279801/test/tools/llvm-symbolizer/print_context.c:16:11: error: expected string not found in input // CHECK: inc ^ <stdin>:1:1: note: scanning from here _fini ^ <stdin>:1:3: note: possible intended match here _fini ^ =================================================================== |
Sylvestre <sylvestre@debian.org> | no | 2016-08-26 | ||
| disable-path-test-failing.diff | =================================================================== | no | ||||
| test-keep-alive.diff | =================================================================== | no | ||||
| scan-build-clang-path.diff | no | |||||
| install-scan-build-py.diff | no | |||||
| scan-view-fix-path.diff | =================================================================== | no | ||||
| fix-scan-view-path.diff | =================================================================== | no | ||||
| lldb/lldb-link-atomic-cmake.patch | Link with -latomic when mips* processor is detected | Gianfranco Costamagna <locutusofborg@debian.org> | no | 2016-07-27 | ||
| lldb/lldb-addversion-suffix-to-llvm-server-exec.patch | lldb-server exec users always /usr/bin/lldb-server. Server is required for any debugging with lldb which makes it unusable unless default version package has been installed. Small changes to code and debian/rules allows a workaround for lldb-server start up. To use this one needs to add cmake definition during configure. eg -DDEBIAN_VERSION_SUFFIX=-$(LLVM_VERSION) Better implementation would be to use /usr/share/llvm-$(VERSION)/bin but that change seems to require a big change to the path handling code which could then break something else. This probably should have upstream bug but I couldn't find any existing report. =================================================================== |
no | ||||
| lldb/lldb-missing-install.diff | =================================================================== | no | ||||
| lldb/lldb-disable-swig-error.diff | =================================================================== | no | ||||
| disable-error-xray.diff | =================================================================== | no | ||||
| openmp/openmp-check-execstack.diff | =================================================================== | no | ||||
| openmp/openmp-mips-affinity.patch | =================================================================== | no | ||||
| openmp/bootstrap-with-openmp-version-export-missing.diff | =================================================================== | no | ||||
| libcxx/libcxxabi-test-don-t-fail-extended-long-double.patch | Powerpc has extended double that doesn't match x86 coding. Power format would need special tests to verify correctness but for now it is enough to prevent incorrect test from running. =================================================================== |
no | ||||
| libcxx/libcxx-test-fix-lockfree-test-for-i386.patch | Lock is_always_lock free test fails on i386 because std::atomic is aligned to 8 bytes while long long is aligned to 4 bytes. clang can't generate inline code for unaligned 8 byte atomics even tough instruction set and gcc support it. That makes it expected thaqt ATOMIC_LLONG_LOCK_FREE and std::atomic<long long>::is_always_lock_free don't match on i386. Correct test for std::atomic<long long> is to check if target cpu support cmpxchg8 instruction. To set instruction support one can check __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 define. =================================================================== |
yes | upstream | |||
| libcxx/libcxxabi-arm-ehabi-fix.patch | Fix arm EHABI code to work. armhf had exception test failing without EHABI support. No known upstream bug about this. Actual code change is more like workaround than something that upstream would accept. Proper fix would be adding _Unwind_Control_Block to clang unwind.h. _Unwind_Control_Block should also extend _Unwind_Exception to make sure their ABI stays in sync. No known upstream bug about this. =================================================================== |
no | ||||
| libcxx/libcxx-test-atomics-set-compare-exchange-to-be-expected-fails-on-arm.patch | Clang 3.9 regression causes a bug when generating code for std::atomic_compare_and_exchange*(std::atomic<long long>,...) without optimizations. If same code is compiled with -O2 tests pass without problems. Atomics are implement in headers with builtin functions which makes this affect application code instead of libc++ library code. libcxx tests default to -O0 compilation so these test need to be marked failing on arm to allow installing packages. Use cases is so borderline failure that it shouldn't prevent building the package. (64bit atomics in 32bit mode) =================================================================== |
no | ||||
| libcxx/libcxx-silent-test-libcxx.diff | =================================================================== | no | ||||
| libcxx/libcxx-silent-failure-ppc64el.diff | =================================================================== | no | ||||
| libcxx/libcxx-silent-failure-arm64.diff | =================================================================== | no | ||||
| mips-fpxx-enable.diff | =================================================================== | no | ||||
| mips-force-nomadd4.diff | The MIPS port aims to support the Loongson 3 family of CPUs in addition of the other MIPS CPUs. On the Loongson 3 family the MADD4 instructions are fused, while they are not fused on the other MIPS CPUs. In order to support both, we have to disabled those instructions. For that, the patch below basically corresponds to the --with-madd4=no used on the GCC side. |
no | ||||
| 26-set-correct-float-abi.diff | set correct float abi settings for armel and armhf debian armel supports systems that don't have a fpu so should use a "float abi" setting of soft by default. Debian armhf needs a float abi setting of "hard" |
Peter Michael Green <plugwash@debian.org> | no | |||
| clang-baseline-fix-i386.patch | =================================================================== | no | ||||
| disable-sse2-old-x86.diff | =================================================================== | no | ||||
| clang-arm-default-vfp3-on-armv7a.patch | =================================================================== | no | ||||
| clangd-atomic-cmake.patch | =================================================================== | no | ||||
| remove-apple-clang-manpage.diff | =================================================================== | no | ||||
| 0049-Use-Debian-provided-MathJax-everywhere.patch | Use Debian-provided MathJax everywhere. | Nicholas D Steeves <nsteeves@gmail.com> | no | 2018-02-10 | ||
| hurd/hurd-pathmax.diff | =================================================================== | no | ||||
| hurd/hurd-cxx-paths.diff | This should be factorized with Linux.cpp and the GNU/kFreeBSD case. =================================================================== |
no | ||||
| 930008-arm.diff | =================================================================== | no | ||||
| bootstrap-fix-include-next.diff | When doing a bootstrap, we use a newly built clang. When this one is used, if already installed on the system, we have clang header in two places: llvm-toolchain-7-7/build-llvm/lib/clang/7.0.0/include/inttypes.h and /usr/include/clang/7.0.0/include/inttypes.h Because clang expects only one of his headers to be available, it uses include_next to get the glibc (libc6-dev package) header. However, in the previous example, because we have inttypes.h twice in the include search path, clang's header will call itself without any effect. Therefore, it will do include_next until the define from the libc is existing (ex: _INTTYPES_H) =================================================================== |
no | ||||
| clang-riscv64-multiarch.diff | =================================================================== | no | ||||
| clang-riscv64-rv64gc.diff | =================================================================== | no | ||||
| llvm-riscv64-fix-cffi.diff | commit c6b09bff5671600f8e764d3847023d0996f328d9 [RISCV] Fix wrong CFI directives Summary: Removes CFI CFA directives that could incorrectly propagate beyond the basic block they were inteded for. Specifically it removes the epilogue CFI directives. See the branch_and_tail_call test for an example of the issue. Should fix the stack unwinding issues caused by the incorrect directives. Reviewers: asb, lenary, shiva0217 Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D69723 |
Luís Marques <luismarques@lowrisc.org> | no | 2019-11-14 | ||
| D60657-riscv-pcrel_lo.diff | commit 41449c58c58e466bcf9cdc4f7415950382bad8d7 [RISCV] Fix evaluation of %pcrel_lo The following testcase function: .Lpcrel_label1: auipc a0, %pcrel_hi(other_function) addi a1, a0, %pcrel_lo(.Lpcrel_label1) .p2align 2 # Causes a new fragment to be emitted .type other_function,@function other_function: ret exposes an odd behaviour in which only the %pcrel_hi relocation is evaluated but not the %pcrel_lo. $ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r - <stdin>: file format ELF64-riscv Disassembly of section .text: 0000000000000000 function: 0: 17 05 00 00 auipc a0, 0 4: 93 05 05 00 mv a1, a0 0000000000000004: R_RISCV_PCREL_LO12_I other_function+4 0000000000000008 other_function: 8: 67 80 00 00 ret The reason seems to be that in RISCVAsmBackend::shouldForceRelocation we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we consider the section. This usually works but there are cases where the section may still be the same but the fragment may be another one. In that case we end forcing a %pcrel_lo relocation without any %pcrel_hi. This patch makes RISCVAsmBackend::shouldForceRelocation use the section, if any, to determine if the relocation must be forced or not. Differential Revision: https://reviews.llvm.org/D60657 diff --git a/llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp b/llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp index f6b727ae37c..5881a0a86ef 100644 |
Roger Ferrer Ibanez <roger.ferrer@bsc.es> | no | 2019-11-08 | ||
| D74453-riscv-atomic_cmp_xchg.diff | [PATCH] [LegalizeTypes][RISCV] Correctly sign-extend comparison for ATOMIC_CMP_XCHG Summary: Currently, the comparison argument used for ATOMIC_CMP_XCHG is legalised with GetPromotedInteger, which leaves the upper bits of the value undefind. Since this is used for comparing in an LR/SC loop with a full-width comparison, we must sign extend it. We introduce a new getExtendForAtomicCmpSwapArg to complement getExtendForAtomicOps, since many targets have compare-and-swap instructions (or pseudos) that correctly handle an any-extend input, and the existing function determines the extension of the result, whereas we are concerned with the input. This is related to https://reviews.llvm.org/D58829, which solved the issue for ATOMIC_CMP_SWAP_WITH_SUCCESS, but not the simpler ATOMIC_CMP_SWAP. Reviewed By: asb Differential Revision: https://reviews.llvm.org/D74453 |
Jessica Clarke <jrtc27@jrtc27.com> | no | 2020-04-01 | ||
| D67877.patch | =================================================================== | no | debian | https://reviews.llvm.org/D67877 | ||
| disable-lit-cpuid-install.diff | =================================================================== | no | ||||
| no-z3.patch | Description: Disable z3 to avoid pulling ocaml into main. For some reason the cmake option LLVM_ENABLE_Z3_SOLVER was not taken into account =================================================================== |
Gianfranco Costamagna <locutusofborg@debian.org> | no | 2019-11-26 | ||
| x86-fuzzer.patch | fuzzer: EMULATION_ARGUMENT is also required when building on i386 for x86_64 | Adrian Bunk <bunk@debian.org> | no | |||
| D71028-mips-rust-test.diff | [PATCH] [Mips] Add support for min/max/umin/umax atomics In order to properly implement these atomic we need one register more than other binary atomics. It is used for storing result from comparing values in addition to the one that is used for actual result of operation. https://reviews.llvm.org/D71028 [Backported to 9 by replacing Register with unsigned] |
Mirko Brkusanin <Mirko.Brkusanin@rt-rk.com> | no | 2019-12-12 | ||
| python3-shebang.patch | change all shebangs to Python3 find . -name "*.py" -exec sed "s|\!/usr/bin/env python$|\!/usr/bin/env python3|g" -i {} \; | no | ||||
| print-lldb-path.patch | =================================================================== | Gianfranco Costamagna <locutusofborg@debian.org> | no | 2020-01-21 | ||
| no-cgi.patch | cgi method is deprecated, use html instead | Gianfranco Costamagna <locutusofborg@debian.org> | no | 2020-02-25 | ||
| 947f9692440836dcb8d88b74b69dd379d85974ce.patch | [PATCH] Fix sanitizer-common build with glibc 2.31 Summary: As mentioned in D69104, glibc changed ABI recently with the [[ https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2f959dfe849e0646e27403f2e4091536496ac0f0| 2f959dfe ]] change. D69104 dealt with just 32-bit ARM, but that is just one of the many affected architectures. E.g. x86_64, i?86, riscv64, sparc 32-bit, s390 31-bit are affected too (and various others). This patch instead of adding a long list of further architectures that wouldn't be checked ever next to arm 32-bit changes the structures to match the 2.31 layout and performs the checking on Linux for ipc_perm mode position/size only on non-Linux or on Linux with glibc 2.31 or later. I think this matches what is done for aarch64 already. If needed, we could list architectures that haven't changed ABI (e.g. powerpc), so that they would be checked even with older glibcs. AFAIK sanitizers don't actually use ipc_perm.mode and so all they care about is the size and alignment of the whole structure. Note, s390 31-bit and arm 32-bit big-endian changed ABI even further, there will now be shmctl with old symbol version and shmctl@@GLIBC_2.31 which will be incompatible. I'm afraid this isn't really solvable unless the sanitizer libraries are symbol versioned and use matching symbol versions to glibc symbols for stuff they intercept, plus use dlvsym. This patch doesn't try to address that. Patch by Jakub Jelinek. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D70662 |
Evgenii Stepanov <eugenis@google.com> | no | 2019-11-25 | ||
| riscv64-multilib-empty.patch | =================================================================== | no | ||||
| 373184.patch | [PATCH] Revert "[SCEV] add no wrap flag for SCEVAddExpr." This reverts r366419 because the analysis performed is within the context of the loop and it's only valid to add wrapping flags to "global" expressions if they're always correct. (cherry picked from commit 58e8c793d0e43150a6452e971a32d7407a8a7401) |
Tim Northover <tnorthover@apple.com> | no | 2019-09-30 | ||
| f8e146f3430de3a6cd904f3f3f7aa1bfaefee14c.patch | [PATCH] [InstCombine] Fix big-endian miscompile of (bitcast (zext/trunc (bitcast))) Summary: optimizeVectorResize is rewriting patterns like: %1 = bitcast vector %src to integer %2 = trunc/zext %1 %dst = bitcast %2 to vector Since bitcasting between integer an vector types gives different integer values depending on endianness, we need to take endianness into account. As it happens the old implementation only produced the correct result for little endian targets. Reviewed By: spatel, lebedev.ri Differential Revision: https://reviews.llvm.org/D70844 (cherry picked from commit a9d6b0e5444741d08ff1df7cf71d1559e7fefc1f) |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> | no | 2019-11-28 | ||
| 3185c30c54d0af5bffbff3bcfd721668d086ff10.patch | [PATCH] Prefer __vector over vector keyword for altivec `vector' uses the keyword-and-predefine mode from gcc, while __vector is reliably supported. As a side effect, it also makes the code consistent in its usage of __vector. Differential Revision: https://reviews.llvm.org/D74129 |
serge-sans-paille <sguelton@redhat.com> | no | 2020-02-06 | ||
| llvm9-D71443-PPC-MC-redef-symbol.patch | [PATCH] [MC][PowerPC] Fix a crash when redefining a symbol after .set Fix PR44284. This is probably not valid assembly but we should not crash. Reviewed By: luporl, #powerpc, steven.zhang Differential Revision: https://reviews.llvm.org/D71443 (cherry picked from commit f99eedeb72644671cd584f48e4c136d47f6b0020) |
Fangrui Song <maskray@google.com> | no | 2019-12-12 | ||
| llvm-9.0-D78196.patch | diff --git a/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp b/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.cpp | no |