Control: clone -1 -2
Control: unblock 1095863 by -2
Control: retitle -2 llvm-toolchain-20: unsoundness/miscompilations on i386
Control: reassign -2 src:llvm-toolchain-20
On Fri, 25 Apr 2025 at 17:19:49 +0200, Fabian Grünbichler wrote:
IMHO llvm-19 should definitely be adapted as well to fix the issue on the
LLVM side as well. compiling and executing the C reproducer[0] on i386 using
`clang-18 -O3 code.c && ./a.out` works fine, doing the same with clang-19
causes a segfault. with clang-18 downgraded to 1:18.1.8-16 (last version
before the baseline bump) the segfault is back as expected.
On Fri, Apr 25, 2025, at 11:56 AM, Simon McVittie wrote:
Will llvm-toolchain-20 prereleases (in experimental) also need an
upload? The llvm-toolchain-20 package doesn't seem to have a bug open
yet - should we clone this one?
if they still use the lowered/old baseline, yes.
The 20 branch still seems to have disable-sse2-old-x86.diff and
clang-baseline-fix-i386.patch, which are the patches that were dropped
in order to resolve this in the 18 branch, so I think yes it is still
using the lower baseline. Cloning as requested.
If I'm reading correctly, disable-sse2-old-x86.diff and
clang-baseline-fix-i386.patch will need to be dropped from both the 20
branch (for src:llvm-toolchain-20) and the snapshot branch (for a future
src:llvm-toolchain-21) to avoid this regressing in future. The
equivalent of cherry-picking these commits from the 18 branch:
*
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/f3af06cdcb77523f7a461a2de35c52daafcab311
*
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/90035ab5f2c7b352faf6fd45c303d15f6ebeb25c
*
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/02b16baed84d68bdee9b6a48a76f0786fc24e7ff
*
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/b6c80b9fa2e547e2fabd5df45ed0b75af45da2cb
20 is not slated for
Trixie though, so it's not as pressing there atm.
It's still an equally serious bug in the package, even if it's only
going to be a practical problem in forky, so I think it's worth
tracking. This seems like the sort of change that is best made
systematically across all branches as a batch, to avoid having it
accidentally regress when updating to a new LLVM branch.
smcv
