fix bitcast of single-element SIMD vectors #143194

folkertdev · 2025-06-29T13:35:15Z

in effect this reverts #142768 and adds additional tests. That PR relaxed the conditions on an early return in an incorrect way that would create broken LLVM IR.

https://godbolt.org/z/PaaGWTv5a

#![feature(repr_simd)]

#[repr(simd)]
#[derive(Clone, Copy)]
struct S([i64; 1]);

#[no_mangle]
pub extern "C" fn single_element_simd(b: S) -> i64 {
    unsafe { std::mem::transmute(b) }
}

at the time of writing generates this LLVM IR, where the type of the return is different from the function's return type.

define noundef i64 @single_element_simd(<1 x i64> %b) unnamed_addr {
start:
  ret <1 x i64> %b
}

The test output is actually the same for the existing tests, showing that the change didn't actually matter for any tested behavior. It is probably a bit faster to do the early return, but, well, it's incorrect in general.

zullip thread: #t-compiler > Is transmuting a `T` to `Tx1` (one-element SIMD vector) UB?
cc @sayantn
r? @scottmcm

rustbot · 2025-06-29T13:35:21Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

workingjubilee · 2025-06-29T16:39:55Z

Thanks.

@bors r+ rollup

bors · 2025-06-29T16:39:58Z

📌 Commit 51e1666 has been approved by workingjubilee

It is now in the queue for this repository.

…-bitcast, r=workingjubilee fix bitcast of single-element SIMD vectors in effect this reverts rust-lang#142768 and adds additional tests. That PR relaxed the conditions on an early return in an incorrect way that would create broken LLVM IR. https://godbolt.org/z/PaaGWTv5a ```rust #![feature(repr_simd)] #[repr(simd)] #[derive(Clone, Copy)] struct S([i64; 1]); #[no_mangle] pub extern "C" fn single_element_simd(b: S) -> i64 { unsafe { std::mem::transmute(b) } } ``` at the time of writing generates this LLVM IR, where the type of the return is different from the function's return type. ```llvm define noundef i64 `@single_element_simd(<1` x i64> %b) unnamed_addr { start: ret <1 x i64> %b } ``` The test output is actually the same for the existing tests, showing that the change didn't actually matter for any tested behavior. It is probably a bit faster to do the early return, but, well, it's incorrect in general. zullip thread: [#t-compiler > Is transmuting a &rust-lang#96;T&rust-lang#96; to &rust-lang#96;Tx1&rust-lang#96; (one-element SIMD vector) UB?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/with/526262799) cc `@sayantn` r? `@scottmcm`

Rollup of 7 pull requests Successful merges: - #142429 (`tests/ui`: A New Order [13/N]) - #143066 (Use let chains in the new solver) - #143156 (inherit `#[align]` from trait method prototypes) - #143176 (fix typos and improve clarity in documentation) - #143187 (Add my work email to mailmap) - #143194 (fix bitcast of single-element SIMD vectors) - #143199 (Re-disable `tests/run-make/short-ice` on Windows MSVC again) r? `@ghost` `@rustbot` modify labels: rollup

scottmcm · 2025-06-30T00:20:10Z

My bad. Thanks for adding more test coverage.

a4lg · 2025-06-30T03:14:11Z

Considering the error message in the CI log, do we need to add something like this?

#![cfg_attr(target_family = "wasm", target_feature(enable = "simd128"))]

matthiaskrgr · 2025-06-30T04:46:08Z

@bors r-
failed here: #143211 (comment)

folkertdev · 2025-06-30T08:41:43Z

Turns out you need a bunch of cfg_attrs for the various platforms (the current set is based on tests/codegen/simd/extract-insert-dyn.rs). I've also made the test use minicore now, which is much more convenient when cross-compiling.

@rustbot ready

folkertdev · 2025-07-01T08:41:36Z

stdarch CI is currently broken because of this issue, it would be nice to get this merged.

workingjubilee · 2025-07-01T17:16:25Z

Oh, sorry!

@bors r+ rollup

bors · 2025-07-01T17:16:27Z

📌 Commit e86fddc has been approved by workingjubilee

It is now in the queue for this repository.

workingjubilee · 2025-07-01T17:18:07Z

compiler/rustc_codegen_ssa/src/mir/rvalue.rs

@@ -1123,7 +1123,7 @@ pub(super) fn transmute_immediate<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>>(
    // While optimizations will remove no-op transmutes, they might still be
    // there in debug or things that aren't no-op in MIR because they change
    // the Rust type but not the underlying layout/niche.
-    if from_scalar == to_scalar {
+    if from_scalar == to_scalar && from_backend_ty == to_backend_ty {


Maybe we should add some more comments on why both of these must obtain. That can happen after this merges and the discussion on Zulip settles though.

The entire function is cursed. It talks about transmuting "immediates" but then takes Scalar information as arguments. This needs some refactoring figuring out which class of types it is meant for, and aligning name and signature and comments.

…-bitcast, r=workingjubilee fix bitcast of single-element SIMD vectors in effect this reverts rust-lang#142768 and adds additional tests. That PR relaxed the conditions on an early return in an incorrect way that would create broken LLVM IR. https://godbolt.org/z/PaaGWTv5a ```rust #![feature(repr_simd)] #[repr(simd)] #[derive(Clone, Copy)] struct S([i64; 1]); #[no_mangle] pub extern "C" fn single_element_simd(b: S) -> i64 { unsafe { std::mem::transmute(b) } } ``` at the time of writing generates this LLVM IR, where the type of the return is different from the function's return type. ```llvm define noundef i64 `@single_element_simd(<1` x i64> %b) unnamed_addr { start: ret <1 x i64> %b } ``` The test output is actually the same for the existing tests, showing that the change didn't actually matter for any tested behavior. It is probably a bit faster to do the early return, but, well, it's incorrect in general. zullip thread: [#t-compiler > Is transmuting a &rust-lang#96;T&rust-lang#96; to &rust-lang#96;Tx1&rust-lang#96; (one-element SIMD vector) UB?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/with/526262799) cc `@sayantn` r? `@scottmcm`

Rollup of 12 pull requests Successful merges: - #141829 (Specialize sleep_until implementation for unix (except mac)) - #141847 (Explain `TOCTOU` on the top of `std::fs`, and reference it in functions) - #142138 (Add `Vec::into_chunks`) - #142321 (Expose elf abi on ppc64 targets) - #142568 (Use the .drectve section for exporting symbols from dlls on Windows) - #142886 (ci: aarch64-gnu: Stop skipping `panic_abort_doc_tests`) - #143038 (avoid suggesting traits from private dependencies) - #143194 (fix bitcast of single-element SIMD vectors) - #143206 (Align attr fixes) - #143258 (Don't recompute `DisambiguatorState` for every RPITIT in trait definition) - #143260 (Use the correct export kind for __rust_alloc_error_handler_should_panic) - #143274 (ci: support optional jobs) r? `@ghost` `@rustbot` modify labels: rollup

…-bitcast, r=workingjubilee fix bitcast of single-element SIMD vectors in effect this reverts rust-lang#142768 and adds additional tests. That PR relaxed the conditions on an early return in an incorrect way that would create broken LLVM IR. https://godbolt.org/z/PaaGWTv5a ```rust #![feature(repr_simd)] #[repr(simd)] #[derive(Clone, Copy)] struct S([i64; 1]); #[no_mangle] pub extern "C" fn single_element_simd(b: S) -> i64 { unsafe { std::mem::transmute(b) } } ``` at the time of writing generates this LLVM IR, where the type of the return is different from the function's return type. ```llvm define noundef i64 ``@single_element_simd(<1`` x i64> %b) unnamed_addr { start: ret <1 x i64> %b } ``` The test output is actually the same for the existing tests, showing that the change didn't actually matter for any tested behavior. It is probably a bit faster to do the early return, but, well, it's incorrect in general. zullip thread: [#t-compiler > Is transmuting a &rust-lang#96;T&rust-lang#96; to &rust-lang#96;Tx1&rust-lang#96; (one-element SIMD vector) UB?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/with/526262799) cc ``@sayantn`` r? ``@scottmcm``

Rollup of 11 pull requests Successful merges: - #141829 (Specialize sleep_until implementation for unix (except mac)) - #141847 (Explain `TOCTOU` on the top of `std::fs`, and reference it in functions) - #142138 (Add `Vec::into_chunks`) - #142321 (Expose elf abi on ppc64 targets) - #142886 (ci: aarch64-gnu: Stop skipping `panic_abort_doc_tests`) - #143038 (avoid suggesting traits from private dependencies) - #143194 (fix bitcast of single-element SIMD vectors) - #143206 (Align attr fixes) - #143258 (Don't recompute `DisambiguatorState` for every RPITIT in trait definition) - #143260 (Use the correct export kind for __rust_alloc_error_handler_should_panic) - #143274 (ci: support optional jobs) r? `@ghost` `@rustbot` modify labels: rollup

…-bitcast, r=workingjubilee fix bitcast of single-element SIMD vectors in effect this reverts rust-lang#142768 and adds additional tests. That PR relaxed the conditions on an early return in an incorrect way that would create broken LLVM IR. https://godbolt.org/z/PaaGWTv5a ```rust #![feature(repr_simd)] #[repr(simd)] #[derive(Clone, Copy)] struct S([i64; 1]); #[no_mangle] pub extern "C" fn single_element_simd(b: S) -> i64 { unsafe { std::mem::transmute(b) } } ``` at the time of writing generates this LLVM IR, where the type of the return is different from the function's return type. ```llvm define noundef i64 ```@single_element_simd(<1``` x i64> %b) unnamed_addr { start: ret <1 x i64> %b } ``` The test output is actually the same for the existing tests, showing that the change didn't actually matter for any tested behavior. It is probably a bit faster to do the early return, but, well, it's incorrect in general. zullip thread: [#t-compiler > Is transmuting a &rust-lang#96;T&rust-lang#96; to &rust-lang#96;Tx1&rust-lang#96; (one-element SIMD vector) UB?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/with/526262799) cc ```@sayantn``` r? ```@scottmcm```

Rollup of 12 pull requests Successful merges: - #141847 (Explain `TOCTOU` on the top of `std::fs`, and reference it in functions) - #142138 (Add `Vec::into_chunks`) - #142321 (Expose elf abi on ppc64 targets) - #142886 (ci: aarch64-gnu: Stop skipping `panic_abort_doc_tests`) - #143038 (avoid suggesting traits from private dependencies) - #143194 (fix bitcast of single-element SIMD vectors) - #143206 (Align attr fixes) - #143231 (Suggest use another lifetime specifier instead of underscore lifetime) - #143232 ([COMPILETEST-UNTANGLE 3/N] Use "directives" consistently within compiletest) - #143258 (Don't recompute `DisambiguatorState` for every RPITIT in trait definition) - #143260 (Use the correct export kind for __rust_alloc_error_handler_should_panic) - #143274 (ci: support optional jobs) r? `@ghost` `@rustbot` modify labels: rollup

…-bitcast, r=workingjubilee fix bitcast of single-element SIMD vectors in effect this reverts rust-lang#142768 and adds additional tests. That PR relaxed the conditions on an early return in an incorrect way that would create broken LLVM IR. https://godbolt.org/z/PaaGWTv5a ```rust #![feature(repr_simd)] #[repr(simd)] #[derive(Clone, Copy)] struct S([i64; 1]); #[no_mangle] pub extern "C" fn single_element_simd(b: S) -> i64 { unsafe { std::mem::transmute(b) } } ``` at the time of writing generates this LLVM IR, where the type of the return is different from the function's return type. ```llvm define noundef i64 ````@single_element_simd(<1```` x i64> %b) unnamed_addr { start: ret <1 x i64> %b } ``` The test output is actually the same for the existing tests, showing that the change didn't actually matter for any tested behavior. It is probably a bit faster to do the early return, but, well, it's incorrect in general. zullip thread: [#t-compiler > Is transmuting a &rust-lang#96;T&rust-lang#96; to &rust-lang#96;Tx1&rust-lang#96; (one-element SIMD vector) UB?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/with/526262799) cc ````@sayantn```` r? ````@scottmcm````

Rollup of 11 pull requests Successful merges: - #141847 (Explain `TOCTOU` on the top of `std::fs`, and reference it in functions) - #142138 (Add `Vec::into_chunks`) - #142321 (Expose elf abi on ppc64 targets) - #142886 (ci: aarch64-gnu: Stop skipping `panic_abort_doc_tests`) - #143038 (avoid suggesting traits from private dependencies) - #143194 (fix bitcast of single-element SIMD vectors) - #143231 (Suggest use another lifetime specifier instead of underscore lifetime) - #143232 ([COMPILETEST-UNTANGLE 3/N] Use "directives" consistently within compiletest) - #143258 (Don't recompute `DisambiguatorState` for every RPITIT in trait definition) - #143260 (Use the correct export kind for __rust_alloc_error_handler_should_panic) - #143274 (ci: support optional jobs) r? `@ghost` `@rustbot` modify labels: rollup

…-bitcast, r=workingjubilee fix bitcast of single-element SIMD vectors in effect this reverts rust-lang#142768 and adds additional tests. That PR relaxed the conditions on an early return in an incorrect way that would create broken LLVM IR. https://godbolt.org/z/PaaGWTv5a ```rust #![feature(repr_simd)] #[repr(simd)] #[derive(Clone, Copy)] struct S([i64; 1]); #[no_mangle] pub extern "C" fn single_element_simd(b: S) -> i64 { unsafe { std::mem::transmute(b) } } ``` at the time of writing generates this LLVM IR, where the type of the return is different from the function's return type. ```llvm define noundef i64 `````@single_element_simd(<1````` x i64> %b) unnamed_addr { start: ret <1 x i64> %b } ``` The test output is actually the same for the existing tests, showing that the change didn't actually matter for any tested behavior. It is probably a bit faster to do the early return, but, well, it's incorrect in general. zullip thread: [#t-compiler > Is transmuting a &rust-lang#96;T&rust-lang#96; to &rust-lang#96;Tx1&rust-lang#96; (one-element SIMD vector) UB?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/with/526262799) cc `````@sayantn````` r? `````@scottmcm`````

Rollup of 10 pull requests Successful merges: - #141847 (Explain `TOCTOU` on the top of `std::fs`, and reference it in functions) - #142138 (Add `Vec::into_chunks`) - #142321 (Expose elf abi on ppc64 targets) - #142886 (ci: aarch64-gnu: Stop skipping `panic_abort_doc_tests`) - #143194 (fix bitcast of single-element SIMD vectors) - #143231 (Suggest use another lifetime specifier instead of underscore lifetime) - #143232 ([COMPILETEST-UNTANGLE 3/N] Use "directives" consistently within compiletest) - #143258 (Don't recompute `DisambiguatorState` for every RPITIT in trait definition) - #143260 (Use the correct export kind for __rust_alloc_error_handler_should_panic) - #143274 (ci: support optional jobs) r? `@ghost` `@rustbot` modify labels: rollup

Rollup of 9 pull requests Successful merges: - #141847 (Explain `TOCTOU` on the top of `std::fs`, and reference it in functions) - #142138 (Add `Vec::into_chunks`) - #142321 (Expose elf abi on ppc64 targets) - #142886 (ci: aarch64-gnu: Stop skipping `panic_abort_doc_tests`) - #143194 (fix bitcast of single-element SIMD vectors) - #143231 (Suggest use another lifetime specifier instead of underscore lifetime) - #143232 ([COMPILETEST-UNTANGLE 3/N] Use "directives" consistently within compiletest) - #143258 (Don't recompute `DisambiguatorState` for every RPITIT in trait definition) - #143274 (ci: support optional jobs) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #143194 - folkertdev:fix-single-element-simd-bitcast, r=workingjubilee fix bitcast of single-element SIMD vectors in effect this reverts #142768 and adds additional tests. That PR relaxed the conditions on an early return in an incorrect way that would create broken LLVM IR. https://godbolt.org/z/PaaGWTv5a ```rust #![feature(repr_simd)] #[repr(simd)] #[derive(Clone, Copy)] struct S([i64; 1]); #[no_mangle] pub extern "C" fn single_element_simd(b: S) -> i64 { unsafe { std::mem::transmute(b) } } ``` at the time of writing generates this LLVM IR, where the type of the return is different from the function's return type. ```llvm define noundef i64 ``````@single_element_simd(<1`````` x i64> %b) unnamed_addr { start: ret <1 x i64> %b } ``` The test output is actually the same for the existing tests, showing that the change didn't actually matter for any tested behavior. It is probably a bit faster to do the early return, but, well, it's incorrect in general. zullip thread: [#t-compiler > Is transmuting a `T` to `Tx1` (one-element SIMD vector) UB?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Is.20transmuting.20a.20.60T.60.20to.20.60Tx1.60.20.28one-element.20SIMD.20vector.29.20UB.3F/with/526262799) cc ``````@sayantn`````` r? ``````@scottmcm``````

mati865 · 2025-07-03T00:06:53Z

This issue can happen in specific conditions even without nightly features, right?
If so, we should probably backport it to the beta.

rustbot assigned scottmcm Jun 29, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 29, 2025

folkertdev mentioned this pull request Jun 29, 2025

std_detect: Tidying of slice length rust-lang/stdarch#1838

Open

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 29, 2025

GuillaumeGomez mentioned this pull request Jun 29, 2025

Rollup of 7 pull requests #143211

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 30, 2025

fix bitcast of single-element SIMD vectors

e86fddc

folkertdev force-pushed the fix-single-element-simd-bitcast branch from 51e1666 to e86fddc Compare June 30, 2025 08:39

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 30, 2025

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 1, 2025

workingjubilee self-assigned this Jul 1, 2025

workingjubilee reviewed Jul 1, 2025

View reviewed changes

jhpratt mentioned this pull request Jul 1, 2025

Rollup of 12 pull requests #143305

Closed

jhpratt mentioned this pull request Jul 2, 2025

Rollup of 11 pull requests #143311

Closed

jhpratt mentioned this pull request Jul 2, 2025

Rollup of 12 pull requests #143313

Closed

matthiaskrgr mentioned this pull request Jul 2, 2025

Rollup of 11 pull requests #143317

Closed

matthiaskrgr mentioned this pull request Jul 2, 2025

Rollup of 10 pull requests #143322

Closed

matthiaskrgr mentioned this pull request Jul 2, 2025

Rollup of 9 pull requests #143337

Merged

bors merged commit 4f44014 into rust-lang:master Jul 2, 2025
10 checks passed

rustbot added this to the 1.90.0 milestone Jul 2, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix bitcast of single-element SIMD vectors #143194

fix bitcast of single-element SIMD vectors #143194

Uh oh!

folkertdev commented Jun 29, 2025

Uh oh!

rustbot commented Jun 29, 2025

Uh oh!

workingjubilee commented Jun 29, 2025

Uh oh!

bors commented Jun 29, 2025

Uh oh!

scottmcm commented Jun 30, 2025

Uh oh!

a4lg commented Jun 30, 2025 •

edited

Loading

Uh oh!

matthiaskrgr commented Jun 30, 2025

Uh oh!

folkertdev commented Jun 30, 2025

Uh oh!

folkertdev commented Jul 1, 2025

Uh oh!

workingjubilee commented Jul 1, 2025

Uh oh!

bors commented Jul 1, 2025

Uh oh!

workingjubilee Jul 1, 2025 •

edited

Loading

Uh oh!

RalfJung Jul 1, 2025 •

edited

Loading

Uh oh!

Uh oh!

mati865 commented Jul 3, 2025

Uh oh!

Uh oh!

fix bitcast of single-element SIMD vectors #143194

fix bitcast of single-element SIMD vectors #143194

Uh oh!

Conversation

folkertdev commented Jun 29, 2025

Uh oh!

rustbot commented Jun 29, 2025

Uh oh!

workingjubilee commented Jun 29, 2025

Uh oh!

bors commented Jun 29, 2025

Uh oh!

scottmcm commented Jun 30, 2025

Uh oh!

a4lg commented Jun 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

matthiaskrgr commented Jun 30, 2025

Uh oh!

folkertdev commented Jun 30, 2025

Uh oh!

folkertdev commented Jul 1, 2025

Uh oh!

workingjubilee commented Jul 1, 2025

Uh oh!

bors commented Jul 1, 2025

Uh oh!

workingjubilee Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mati865 commented Jul 3, 2025

Uh oh!

Uh oh!

a4lg commented Jun 30, 2025 •

edited

Loading

workingjubilee Jul 1, 2025 •

edited

Loading

RalfJung Jul 1, 2025 •

edited

Loading