Bug#1095866: clone as: llvm-toolchain-20: unsoundness/miscompilations on i386

[Simon McVittie]

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