#1104337 llvm-toolchain-20: unsoundness/miscompilations on i386

#1104337#5
Date:
2025-02-13 06:51:29 UTC
From:
To:
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

#1104337#18
Date:
2025-04-25 09:56:20 UTC
From:
To:
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)

#1104337#27
Date:
2025-04-25 15:19:49 UTC
From:
To:
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.

#1104337#32
Date:
2025-04-25 15:35:39 UTC
From:
To:
and this 19 here should of course been an 18 (hopefully clear from context,
but better make it explicit rather than causing more confusion!).

#1104337#37
Date:
2025-04-29 10:09:31 UTC
From:
To:
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

#1104337#52
Date:
2026-08-18 16:37:48 UTC
From:
To:
Closing bugs reported against llvm-toolchain-20 now that it got removed
from the archive.
----- Message transféré de Debian Bug Tracking System <owner@bugs.debian.org> ----- From: Debian Bug Tracking System <owner@bugs.debian.org> To: Sylvestre Ledru <sylvestre@debian.org> Reply-To: 1116216@bugs.debian.org X-Mailer: MIME-tools 5.510 (Entity 5.510) Date: Tue, 14 Jul 2026 09:33:02 +0000 Subject: Bug#1116216 closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org> (Bug#1116216: Removed package(s) from experimental) Message-ID: <handler.1116216.D1116216.17840214462041426.notifdone@bugs.debian.org> This is an automatic notification regarding your Bug report which was filed against the ftp.debian.org package: #1116216: RM: llvm-toolchain-20/experimental -- ROM; Won't be in unstable It has been closed by Debian FTP Masters <ftpmaster@ftp-master.debian.org>. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Debian FTP Masters <ftpmaster@ftp-master.debian.org> by replying to this email.
------------------- Reason ------------------- ROM; Won't be in unstable ---------------------------------------------- Note that the package(s) have simply been removed from the tag database and may (or may not) still be in the pool; this is not a bug. The package(s) will be physically removed automatically when no suite references them (and in the case of source, when no binary references it). Please also remember that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. Packages are usually not removed from testing by hand. Testing tracks unstable and will automatically remove packages which were removed from unstable when removing them from testing causes no dependency problems. The release team can force a removal from testing if it is really needed, please contact them if this should be the case. Bugs which have been reported against this package are not automatically removed from the Bug Tracking System. Please check all open bugs and close them or re-assign them to another package if the removed package was superseded by another one. The version of this package that was in Debian prior to this removal can still be found using https://snapshot.debian.org/. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1116216@bugs.debian.org. The full log for this bug can be viewed at https://bugs.debian.org/1116216 This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain) From: Sylvestre Ledru <sylvestre@debian.org> To: Debian Bug Tracking System <submit@bugs.debian.org> X-Mailer: reportbug 13.2.0 X-Spam-Status: No, score=-31.0 required=4.0 tests=BAYES_00, BODY_INCLUDES_CONTROL_AFFECTS,BODY_INCLUDES_PACKAGE,FROMDEVELOPER, HAS_PACKAGE,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED, SPF_HELO_NONE,SPF_NONE,XMAILER_REPORTBUG autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 Date: Wed, 24 Sep 2025 13:16:18 +0200 Subject: RM: llvm-toolchain-20/experimental -- ROM; Won't be in unstable Message-ID: <175871257897.3751907.3638191059166209781.reportbug@burias.ecranbleu.org> Package: ftp.debian.org Severity: normal X-Debbugs-Cc: llvm-toolchain-20@packages.debian.org Control: affects -1 + src:llvm-toolchain-20 User: ftp.debian.org@packages.debian.org Usertags: remove Hello, Please remove llvm-toolchain-20 from experimental To make our life easier, i won't be uploading in unstable. We have now 21 and 19 if needed. thanks Sylvestre
----- Fin du message transféré -----