Filing this bug to have a record in BTS - I'll file a separate one for
release.debian.org about the broader baseline question.

This issue came up back in November on debian-devel/-release:

https://lists.debian.org/debian-release/2024/11/msg00443.html

My original mail, partially wrongly summarizing the issue.

https://lists.debian.org/debian-release/2024/11/msg00445.html

My reponse linking to more upstream details, including why downgrading to i586
in LLVM/rustc doesn't work.

It boils down to the following:

- Debian's i386 baseline is currently 32-bit x86 without MMX or SSE (i686)
- Debian's LLVM and rustc packages accordingly patch their i686 targets to
  remove SSE support, which would be part of that target's baseline upstream
  otherwise [0,1]
- Upstream LLVM and rustc consider this combination unsound and unfixable (for
  IMHO valid reasons) because it can cause subtle miscompilations leading to
  runtime crashes, in addition to the (usual, expected) different semantics of
  x87 and SSE2 floating point implementations [2,3]

I see the following options:

A) bump i386 baseline for Trixie to match LLVM/rustc's upstream i686 target,
   i.e. Pentium 4 *with* MMX and SSE2 (separate RT bug will be filed shortly)

B) RC-ignore this bug and implications for Trixie, bump baseline for Trixie+1

C) remove LLVM and rustc and all their transitive rdeps (this includes Firefox
   and Chromium, most major Desktop environments, sequoia, and probably a bit
   more) on i386 from Trixie, further reducing the usefulness of this arch

Personally (with my rustc maintainer hat on) I have a strong preference for A).

Please keep responses on details of A) to the corresponding release.debian.org
bug!

Fabian

0: https://salsa.debian.org/rust-team/rust/-/blob/debian/sid/debian/patches/behaviour/d-rustc-i686-baseline.patch?ref_type=heads
1: https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/blob/19/debian/patches/clang-baseline-fix-i386.patch
2: https://github.com/rust-lang/compiler-team/issues/808
3: https://github.com/rust-lang/rust/issues/114479#issuecomment-2072052116

Control: retitle -1 llvm-toolchain-19: unsoundness/miscompilations on i386
Control: block 1095863 by -1

This was discussed further with the release team in
https://bugs.debian.org/1095863 where I outlined some additional
options, not all of which had been mentioned as possibilities in #1095862.

The release team have chosen to keep the baseline as "officially" 32-bit
x86 without MMX or SSE, but allow rustc (and LLVM if necessary) to
intentionally violate that baseline in order to produce working code.

Paul Gevers wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095863#70:

However I'm a bit confused about the status of implementing this. There
have been uploads of llvm-toolchain-18 and rustc selecting pentium4
rather than i686 as their baseline, but rustc seems to use libLLVM
version 19 (the same as llvm-defaults), and there has been no upload of
llvm-toolchain-19 with an equivalent change.

Was the rustc upload sufficient to address this problem for Rust code,
or is an upload of llvm-toolchain-19 also needed?

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?

     smcv
     (not a release team member)

I am not entirely sure. the change on the rustc side seems to fix both the
floating point behaviour/precision (no more excess x87 precision), as well
as the known Rust reproducers for the miscompilation part (no more segfaults).

I missed that the LLVM change was *only* done for 19 (and if the rustc
with the raised/reverted baseline would have behaved unexpectedly, I might
have realized sooner!).

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.

0: https://github.com/llvm/llvm-project/issues/89885 , code attached

if they still use the lowered/old baseline, yes. 20 is not slated for
Trixie though, so it's not as pressing there atm.

and this 19 here should of course been an 18 (hopefully clear from context,
but better make it explicit rather than causing more confusion!).

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

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

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

Control: clone -1 -2 -3
Control: found -1 1:19.1.7-6
Control: retitle -2 llvm-toolchain-21: unsoundness/miscompilations on i386
Control: reassign -2 src:llvm-toolchain-21 1:21.1.2-2
Control: retitle -3 llvm-toolchain-snapshot: unsoundness/miscompilations on i386
Control: reassign -3 src:llvm-toolchain-snapshot 1:22~++20250731080150+be449d6b6587-1~exp1

Confirmed still present in current(ish) versions (I didn't try clang-19
1:19.1.7-7 which isn't on my mirror yet).

An easy reproducer on an x86 machine with podman installed and working
(either amd64 or i386 should work, tested on amd64):

$ podman run --rm -it --arch i386 i386/debian:sid-slim
# sed -i -e 's/sid/& experimental/g' /etc/apt/sources.list.d/debian.sources
# apt update
# apt full-upgrade
# apt install curl clang-19 clang-21 clang-22
# curl "https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1095866;filename=code.c;msg=27" > bug.c
# clang-19 -O1 -o19 bug.c && ./19
Segmentation fault (core dumped)
# clang-21 -O1 -o21 bug.c && ./21
Segmentation fault (core dumped)
# clang-22 -O1 -o22 bug.c && ./22
Segmentation fault (core dumped)

(Or run the same thing in your favourite container or virtualization
technology, or a chroot.)

Now that -21 is its own package and -snapshot is a prerelease of version
22, presumably those same fixes need applying to -19, -21 and -snapshot
in order to resolve #1095866, clone -2 and clone -3, respectively.

I assume the equivalent bug in -20 (#1104337) is wontfix now that
removal of -20 has been requested.

Thanks,
     smcv

We believe that the bug you reported is fixed in the latest version of
llvm-toolchain-snapshot, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1116637@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sylvestre Ledru <sylvestre@debian.org> (supplier of updated llvm-toolchain-snapshot package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 19 Oct 2026 17:47:54 +0200
Source: llvm-toolchain-snapshot
Architecture: source
Version: 1:24~++20261025103442+7e3c57157096-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: LLVM Packaging Team <pkg-llvm-team@lists.alioth.debian.org>
Changed-By: Sylvestre Ledru <sylvestre@debian.org>
Closes: 1116637
Changes:
 llvm-toolchain-snapshot (1:24~++20261025103442+7e3c57157096-1~exp1) experimental; urgency=medium
 .
   * Remove OCaml support (and the libllvm-X.Y-ocaml-dev package). Thanks
     to Stephane Glondu for the fix
   * Enable sse2 back on i386 (Closes: #1116637).
     It is now the same as upstream. Thanks to Simon McVittie
   * Ship the clang-doc assets (share/clang-doc/) in clang-tools-X.Y with
     the clang-doc binary instead of clang-X.Y-doc, so that the HTML output
     works (see #1142559)
   * Make the source-path entries of /usr/lib/<triplet>/libc++.modules.json
     absolute, the relative ones only worked from /usr/lib/llvm-X.Y/lib
     (see #1142558)
   * Fix the remove_rpath macro in d/rules: it over-escaped '$' so it never
     stripped anything. clang-query kept its build-dir RUNPATH with a
     trailing ':' which made ld.so look in the current directory (CWE-427).
     (see #1142995)
 .
   [ Changes merged from llvm-toolchain-23 ]
   * libmlir-X.Y-dev: drop the Conflicts against the libmlir-x.y-dev virtual
     package, everything is installed under /usr/lib/llvm-X.Y so it is
     co-installable with the other versions (see #1142996)
   * d/debian-llvm-testsuite.bats: add two tests covering the location of
     the MLIR libraries in /usr/lib/<triplet> and the co-installability
     (see #1142996)
   * Fix the FTBFS with doxygen 1.17: it does not generate jquery.js anymore,
     only replace it by the symlink to libjs-jquery when it exists.
     (see #1151646)
   * libc++-X.Y-dev-wasm32, libc++abi-X.Y-dev-wasm32: also build and ship an
     exception-enabled variant of libc++, libc++abi and libunwind, in
     /usr/lib/wasm32-wasi/eh, used by clang with -fwasm-exceptions. Built
     like wasi-sdk does (exnref, so -mllvm -wasm-use-legacy-eh=false, and
     -lunwind needed at link time). The headers are identical, so shared.
     The non-exception variant stays in the existing location.
     d/p/wasm/wasm-sysroot-usr.diff: keep the eh/noeh include directory
     lookup added upstream.
     d/p/wasm/libunwind-wasm-no-declspec.diff: fix the libunwind build for
     wasm (upstream PR 168449, also used by wasi-sdk).
     Add an autopkgtest. (see #1149144)
   * Don't install a default lldb config file anymore: a versioned one does
     not make much sense and an unversioned one conflicts between versions
     (see #1147981). Thanks to Norbert Lange
   * Fix i386 FTBFS: build LLVMSupport with SSE2 when _Float16 requires it
     (d/p/llvm-support-force-sse2-float16.diff), and disable the precompiled
     headers on x86-32 so that the rest of LLVM does not reuse the +sse2 one.
   * d/debian-llvm-testsuite.bats: use -analyzer-constraints=unsupported-z3,
     upstream renamed the z3 constraint manager backend in LLVM 23
     (see #1145851)
Checksums-Sha1:
 f199bd19167dfd3a160c9411f351a50cae513b2d 15577 llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1.dsc
 2a3df308391e10b0aba4ddd9352089b067d21c6b 253667072 llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096.orig.tar.xz
 74e76e3280b52da7726326f734a680d8b47f6934 194192 llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1.debian.tar.xz
 cff4eb58b7886b45627e2567d1a8512f0824b594 46447 llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1_amd64.buildinfo
Checksums-Sha256:
 618e4d4cb8c2e034fef7be0180fe3e9eba262f8b75ec0c202ec52e3e7b5621c2 15577 llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1.dsc
 243b027d906fc8cf43a19b75529871bceb8a465448a74b46f247c8aa58569ee7 253667072 llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096.orig.tar.xz
 ac8d9bcf5b9e6be826ac1aeb5cbc26e1e61fb9bff34bdf2291fd7dfe8569acbe 194192 llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1.debian.tar.xz
 2d35a75853e8df5f4e499a5070d371f03c37b0063fb5d07758b6a9b9439bc2e3 46447 llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1_amd64.buildinfo
Files:
 59f16abb8e9e944ab0be19c8860315e0 15577 devel optional llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1.dsc
 03e88e6fa96b53394d961850c776dfce 253667072 devel optional llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096.orig.tar.xz
 134660879fd2b6494800c9c07896fdea 194192 devel optional llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1.debian.tar.xz
 ebb0b07119772f6f14cc9c9dc906aaa5 46447 devel optional llvm-toolchain-snapshot_24~++20261025103442+7e3c57157096-1~exp1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAmrfFfIACgkQfmUo2nUv
G+G3SRAAjbXAHYEaPBpvaI5PLNrXwNRAAOW+KhLqLGEIEsTBZCyWblnNAF+8+QEB
kZZOTEbKEoJQf4UKqBKhIXL+JQsP0jzP/5jyW4jsvn9gA6WmAtU6EZApZHXT9HDp
D+Dl9V9W8RQeBqK8gTQJflv1J/b+aqe4NPH7R81Onk1iSCc2lhz7Xb41eynvhGaS
QlqyxYWqnZeCTq+NE/aPGMX8sA+HNvh0ZZkoGDOX9f/aTE3pS/wH7tB9WuH36PWJ
blJCUNvRWUcfhniTgvQtMngN/KGao67pXjEBxJ74hsectb4ODaY48bbcf05K9ngP
J9DO3l9Zo5Mqy+8ohOWgF2euDiSgDEGWm4SFdnVs1tU36wGlXLYrZo1Ex8NLdD8B
9Tp6lQs2sVnhYSPue6fvgemuFaP2TVF6Z/tk6GVBn7p4Jqvb2aL2jW8tv7ChRF5x
GdUAnRAFeiA4Uu/7Trf53sVh98kn2iTY8iPZiaWQVlFs8UeRFT/xet/jIMbsu6F2
1GaiWP24B1gXoh3KyhxP6lwxOjLIg4ZAsMB8SH2BncZO/7bcYrPTNN2MoO4ucmPS
CnnUO0nB0pp3OLA5ZrQ4GBvADxYhNj9bo+Kgz5vS04KTq8l25phOxJn5KWyjyACj
x6uZygj1qM2g3ChbVa1A8t1iouTct7V0LGwMs0Gr24Y+FRLJmZw=
=toEb
-----END PGP SIGNATURE-----