Starting from Rust 1.89, rustc generates wrong intrinsic code call #145357
Description
When we try to update docs.rs toolchain to 1.89 (from 1.88), we end up with SIGILL with this callstack (that I got with valgrind):
vex amd64->IR: unhandled instruction bytes: 0x62 0xF3 0xF5 0x8 0x25 0x6 0x96 0xEB 0x63 0x49
vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR: VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0
==3821763== valgrind: Unrecognised instruction at address 0x5a5e04b.
==3821763== at 0x5A5E04B: _mm_xor_si128 (sse2.rs:862)
==3821763== by 0x5A5E04B: xor3_vectors_sse (x86.rs:335)
==3821763== by 0x5A5E04B: <crc_fast::arch::x86::X86Ops as crc_fast::traits::ArchOps>::xor3_vectors (x86.rs:243)
==3821763== by 0x5A64A84: fold_16<crc_fast::arch::x86::X86Ops> (algorithm.rs:102)
==3821763== by 0x5A64A84: crc_fast::algorithm::get_last_two_xmms (algorithm.rs:0)
==3821763== by 0x5A668B1: process_17_to_31<crc_fast::arch::x86::X86Ops, crc_fast::structs::Width32> (algorithm.rs:407)
==3821763== by 0x5A668B1: crc_fast::algorithm::process_by_strategy (algorithm.rs:142)
==3821763== by 0x5A611BF: update<crc_fast::arch::x86::X86Ops, crc_fast::structs::Width32> (algorithm.rs:0)
==3821763== by 0x5A611BF: update_x86_sse (mod.rs:112)
==3821763== by 0x5A611BF: crc_fast::arch::update (mod.rs:91)
==3821763== by 0x5A693C9: update (lib.rs:430)
==3821763== by 0x5A693C9: update (lib.rs:147)
==3821763== by 0x5A693C9: <aws_smithy_checksums::Crc32 as aws_smithy_checksums::Checksum>::update (lib.rs:164)
==3821763== by 0x5979127: aws_sdk_s3::http_request_checksum::add_checksum_for_request_body (http_request_checksum.rs:318)
==3821763== by 0x5978186: <aws_sdk_s3::http_request_checksum::RequestChecksumInterceptor<AP,CM> as aws_smithy_runtime_api::client::interceptors::Intercept>::modify_before_signing (http_request_checksum.rs:262)
==3821763== by 0x56164E9: aws_smithy_runtime::client::interceptors::Interceptors<I>::modify_before_signing (interceptors.rs:44)
==3821763== by 0x4852B48: aws_smithy_runtime::client::orchestrator::try_attempt::{{closure}} (orchestrator.rs:90)
==3821763== by 0x4B71D9E: <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll (instrument.rs:321)
==3821763== by 0x4884572: aws_smithy_runtime::client::orchestrator::try_op::{{closure}}::{{closure}}::{{closure}} (orchestrator.rs:313)
==3821763== by 0x49E90EF: <aws_smithy_runtime::client::timeout::MaybeTimeoutFuture<InnerFuture> as core::future::future::Future>::poll (timeout.rs:82)
==3821763== Your program just tried to execute an instruction that Valgrind
==3821763== did not recognise. There are two possible reasons for this.
==3821763== 1. Your program has a bug and erroneously jumped to a non-code
==3821763== location. If you are running Memcheck and you just saw a
==3821763== warning about a bad jump, it's probably your program's fault.
==3821763== 2. The instruction is legitimate but Valgrind doesn't handle it,
==3821763== i.e. it's Valgrind's fault. If you think this is the case or
==3821763== you are not sure, please let us know and we'll try to fix it.
==3821763== Either way, Valgrind will now raise a SIGILL signal which will
==3821763== probably kill your program.
==3821763==
==3821763== Process terminating with default action of signal 4 (SIGILL): dumping core
==3821763== Illegal opcode at address 0x5A5E04B
==3821763== at 0x5A5E04B: _mm_xor_si128 (sse2.rs:862)
==3821763== by 0x5A5E04B: xor3_vectors_sse (x86.rs:335)
==3821763== by 0x5A5E04B: <crc_fast::arch::x86::X86Ops as crc_fast::traits::ArchOps>::xor3_vectors (x86.rs:243)
==3821763== by 0x5A64A84: fold_16<crc_fast::arch::x86::X86Ops> (algorithm.rs:102)
==3821763== by 0x5A64A84: crc_fast::algorithm::get_last_two_xmms (algorithm.rs:0)
==3821763== by 0x5A668B1: process_17_to_31<crc_fast::arch::x86::X86Ops, crc_fast::structs::Width32> (algorithm.rs:407)
==3821763== by 0x5A668B1: crc_fast::algorithm::process_by_strategy (algorithm.rs:142)
==3821763== by 0x5A611BF: update<crc_fast::arch::x86::X86Ops, crc_fast::structs::Width32> (algorithm.rs:0)
==3821763== by 0x5A611BF: update_x86_sse (mod.rs:112)
==3821763== by 0x5A611BF: crc_fast::arch::update (mod.rs:91)
==3821763== by 0x5A693C9: update (lib.rs:430)
==3821763== by 0x5A693C9: update (lib.rs:147)
==3821763== by 0x5A693C9: <aws_smithy_checksums::Crc32 as aws_smithy_checksums::Checksum>::update (lib.rs:164)
==3821763== by 0x5979127: aws_sdk_s3::http_request_checksum::add_checksum_for_request_body (http_request_checksum.rs:318)
==3821763== by 0x5978186: <aws_sdk_s3::http_request_checksum::RequestChecksumInterceptor<AP,CM> as aws_smithy_runtime_api::client::interceptors::Intercept>::modify_before_signing (http_request_checksum.rs:262)
==3821763== by 0x56164E9: aws_smithy_runtime::client::interceptors::Interceptors<I>::modify_before_signing (interceptors.rs:44)
==3821763== by 0x4852B48: aws_smithy_runtime::client::orchestrator::try_attempt::{{closure}} (orchestrator.rs:90)
==3821763== by 0x4B71D9E: <tracing::instrument::Instrumented<T> as core::future::future::Future>::poll (instrument.rs:321)
==3821763== by 0x4884572: aws_smithy_runtime::client::orchestrator::try_op::{{closure}}::{{closure}}::{{closure}} (orchestrator.rs:313)
==3821763== by 0x49E90EF: <aws_smithy_runtime::client::timeout::MaybeTimeoutFuture<InnerFuture> as core::future::future::Future>::poll (timeout.rs:82)
Here is the docs.rs PR: rust-lang/docs.rs#2901
I also tested with the current master branch and it has the same issue. It happens on linux but not on mac, didn't test on other platforms.
You can reproduce the bug by running cargo test on docs.rs crate.