| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| 0001-Remove-unrelevant-prebuild-binaries-to-pacify-lintia.patch | Remove unrelevant prebuild binaries to pacify lintian | Roman Lebedev <lebedev.ri@gmail.com> | not-needed | 2021-10-08 | ||
| 0002-Fixup-libhalide-version-soversion-for-debian-package.patch | Fixup libhalide version/soversion for debian package | Roman Lebedev <lebedev.ri@gmail.com> | not-needed | 2022-01-06 | ||
| 0003-Fixup-libHalidePyStubs-version-soversion-for-debian-.patch | Fixup libHalidePyStubs version/soversion for debian package | Roman Lebedev <lebedev.ri@gmail.com> | not-needed | 2023-07-07 | ||
| 0004-Disable-LTO-for-python-stub.patch | Disable LTO for python stub `Halide_PyStubs` static library is installed, but if we build Halide with LTO, it, obviously, contains Clang/LLVM IR representation, not assembly code, so things go awry. |
Roman Lebedev <lebedev.ri@gmail.com> | not-needed | 2024-07-27 | ||
| 0005-XFAIL-some-integration-tests-expecting-static-halide.patch | XFAIL some integration tests expecting static halide / cross-compilation We only build/provide `SHARED` `libHalide`, so the integration tests that expect to find a `STATIC` one, fail. Also stub out the cross-compilation integration test, at least for now. |
Roman Lebedev <lebedev.ri@gmail.com> | not-needed | 2024-07-27 | ||
| 0006-Python_bindings-test-as-installed-8355.patch | `Python_bindings`-test-as-installed (#8355) Support not building python bindings, while running python tests against installed halide, and call `enable_testing()` there so that `ctest` can work. (cherry picked from commit 423df3c50b4b5c9b05b6b2cae16aff535dcf81c0) |
Roman Lebedev <lebedev.ri@gmail.com> | yes | 2024-07-31 | ||
| 0007-mullapudi2016_reorder-make-Autoscheduler-time-1-even.patch | mullapudi2016_reorder: make `Autoscheduler time (1)` even more pessimistic See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076968 |
Roman Lebedev <lebedev.ri@gmail.com> | not-needed | 2024-08-03 | ||
| 0008-Integration-test-do-forward-C-CXX-compiler-to-the-in.patch | Integration test: do forward C/CXX compiler to the inner CMake invocation It is apparently useful to run integration test with both Clang and GCC, but that can't be done if CXX isn't propagated. |
Roman Lebedev <lebedev.ri@gmail.com> | yes | 2024-08-07 | ||
| 0009-_Float16-on-i386-needs-gcc14-SSE2.patch | `_Float16`: on i386, needs gcc14 + SSE2 It is not known by GCC13: https://ci.debian.net/packages/h/halide/testing/i386/50047733/ and fails with ``` /usr/bin/g++ -DHALIDE_ENABLE_RTTI -DHALIDE_VERSION_MAJOR=18 -DHALIDE_VERSION_MINOR=0 -DHALIDE_VERSION_PATCH=0 -DHALIDE_WITH_EXCEPTIONS -isystem /usr/include/halide18 -O3 -DNDEBUG -MD -MT CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d -o CMakeFiles/main.dir/main.cpp.o -c /tmp/autopkgtest.pviDWM/build.Sjp/src/test/integration/jit/main.cpp In file included from /tmp/autopkgtest.pviDWM/build.Sjp/src/test/integration/jit/main.cpp:1: /usr/include/halide18/Halide.h: In member function ‘Halide::float16_t::operator _Float16() const’: /usr/include/halide18/Halide.h:3054:40: error: SSE register return with SSE2 disabled 3054 | explicit operator _Float16() const { | ^ /usr/include/halide18/Halide.h:3057:16: error: SSE register return with SSE2 disabled 3057 | return result; | ^~~~~~ /usr/include/halide18/Halide.h: In constructor ‘Halide::Expr::Expr(_Float16)’: /usr/include/halide18/Halide.h:4679:64: error: invalid conversion from type ‘_Float16’ without option ‘-msse2’ 4679 | : IRHandle(Internal::FloatImm::make(Float(16), (double)x)) { | ^ ``` with GCC14. |
Roman Lebedev <lebedev.ri@gmail.com> | yes | 2024-08-07 | ||
| 0010-JITModule-rework-fix-__udivdi3-handling.patch | JITModule: rework/fix `__udivdi3` handling The original workaround is very partial, and was not really working in my experience, even after making it non-GCC specific. Instead: 1. Ensure that the library that actually provides that symbol (as per the compiler used!) is actually linked into. This was not enough still. 2. Replace `HalideJITMemoryManager` hack with a more direct approach of actually telling the JIT the address of the symbol. 3. While there, move the symbol's forward definition to outside of namespaces. It's a global symbol, it makes sense to place it there. This makes python binding tests pass on i386, and i'm really happy about that. Refs. https://github.com/llvm/llvm-project/issues/61289 Inspired by https://github.com/root-project/root/pull/13286 |
Roman Lebedev <lebedev.ri@gmail.com> | yes | 2024-08-11 |