Bug#1095866: llvm-toolchain-19: unsoundness/miscompilations on i386

[Fabian Grünbichler]

On Fri, Apr 25, 2025, at 11:56 AM, Simon McVittie wrote:
> Control: retitle -1 llvm-toolchain-19: unsoundness/miscompilations on i386
> Control: block 1095863 by -1
>
> On Thu, 13 Feb 2025 at 07:51:29 +0100, Fabian Grünbichler wrote:
>>- 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]
>
> 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:
>>On 13-02-2025 17:32, Simon McVittie wrote:
>>> - Officially keep current baseline, intentionally violate the baseline in
>>>    rustc (and maybe LLVM?) so that rustc produces working code, and
>>>    have the release team announce that the resulting baseline violations
>>>    are not to be considered RC bugs
>>
>>I think we're effectively going with this option, given the upload in
>>[1] that we are aware of and didn't object to.
>>
>>[1] https://tracker.debian.org/news/1627384/accepted-llvm-toolchain-18-11818-17-source-into-unstable/
>
> 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?

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

> 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. 20 is not slated for
Trixie though, so it's not as pressing there atm.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: code.c
Type: text/x-csrc
Size: 1126 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-llvm-team/attachments/20250425/046f2925/attachment.c>