mitigate MSVC alignment issue on x86-32 #139261

RalfJung · 2025-04-02T15:27:22Z

This implements mitigation for #112480 by stopping to emit align attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align u64 and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems.

Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can.

Also add an errata note to the platform support page warning users about this known problem.

try-job: i686-msvc*

rustbot · 2025-04-02T15:27:26Z

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-04-02T15:27:28Z

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

RalfJung · 2025-04-02T15:28:09Z

compiler/rustc_target/src/spec/mod.rs

+    pub fn has_unreliable_alignment(&self) -> bool {
+        // FIXME(#112480) MSVC on x86-32 is unsound and fails to properly align many types with
+        // more-than-4-byte-alignment on the stack.
+        if self.is_like_msvc && self.arch == "x86" {


This function is called a lot during codegen. Should I be worried about the (short) string comparison here?

We can also add a new bool flag to the target spec that directly controls this.

Hm, thinking about this some more it might make sense to make it a part of the target spec so that custom targets can be supported.

Currently we auto-detect this for custom targets, if we make it part of the spec custom target specs will have to remember to do this.

Right but I mean the trade-off is that a potential non-msvc target that's not in-tree will have no way to set this. I don't know how likely that is but you mentioned the possibility earlier. And maybe it's fine in any case if such a targets are likely to have other custom requirements that will necessitate forking.

RalfJung · 2025-04-02T15:30:23Z

This will probably be hellish for the codegen test suite since all the align things are missing now...
@bors try

mitigate MSVC alignment issue on x86-32 This implements mitigation for rust-lang#112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems. Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can. Also add an errata note to the platform support page warning users about this known problem. try-job: `i686-msvc*`

bors · 2025-04-02T15:31:36Z

⌛ Trying commit ce44d17 with merge 21a86ec...

compiler/rustc_target/src/spec/mod.rs

compiler/rustc_codegen_llvm/src/builder.rs

beetrees · 2025-04-02T17:04:54Z

Looking at #112480 (comment), I think the only alignment this PR needs to change as it that a type with an alignment of 8 bytes might only have an alignment of 4 bytes. MSVC will always align primitive types with an alignment < 8 bytes correctly, and the only types with an alignment > 8 bytes are SIMD types which MSVC aligns correctly anyway.

RalfJung · 2025-04-02T19:42:54Z

Looking at #112480 (comment), I think the only alignment this PR needs to change as it that a type with an alignment of 8 bytes might only have an alignment of 4 bytes. MSVC will always align primitive types with an alignment < 8 bytes correctly, and the only types with an alignment > 8 bytes are SIMD types which MSVC aligns correctly anyway.

I'd rather not rely on the "> 8" part. But yeah I think changing the logic to "clamp to 4" rather than "skip applying alignment" will probably be better, also to affect fewer tests.

RalfJung · 2025-04-03T15:48:43Z

@bors try

mitigate MSVC alignment issue on x86-32 This implements mitigation for rust-lang#112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems. Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can. Also add an errata note to the platform support page warning users about this known problem. try-job: `i686-msvc*`

bors · 2025-04-03T15:49:56Z

⌛ Trying commit ca29777 with merge 0b5c0be...

bors · 2025-04-03T17:39:20Z

💔 Test failed - checks-actions

RalfJung · 2025-04-04T13:23:36Z

@saethlin I adjusted the alignment check so that it is still active on MSVC but only checks an alignment of up to 4. I hope I did this right. :D What would be the best way to test this? An only-msvc MIR test?

compiler/rustc_mir_transform/src/check_alignment.rs

tests/codegen/align-struct.rs

RalfJung · 2025-04-04T16:08:04Z

@bors try

mitigate MSVC alignment issue on x86-32 This implements mitigation for rust-lang#112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems. Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can. Also add an errata note to the platform support page warning users about this known problem. try-job: `i686-msvc*`

bors · 2025-04-04T16:09:17Z

⌛ Trying commit df69e5d with merge ae95269...

bors · 2025-04-04T18:54:47Z

☀️ Try build successful - checks-actions
Build commit: ae95269 (ae95269e81a16ddfe3e2acd26241f427eb8ffda5)

src/doc/rustc/src/platform-support.md

beetrees · 2025-04-04T19:44:16Z

I think this also needs to be mitigated on the i686-pc-windows-gnu* targets (which are is_like_windows but not is_like_msvc) that as they can also interact with x86-32 MSVC-built code (such as by calling MSVC-built Windows libraries).

RalfJung · 2025-04-04T19:55:26Z

I think this also needs to be mitigated on the i686-pc-windows-gnu* targets (which are is_like_windows but not is_like_msvc) that as they can also interact with x86-32 MSVC-built code (such as by calling MSVC-built Windows libraries).

I was wondering about that, but the existing logic only kicked in for the MSVC targets.

beetrees · 2025-04-04T20:10:16Z

I think it's just that no-one noticed as i686-pc-windows-gnu is much less popular than i686-pc-windows-msvc.

RalfJung · 2025-04-05T07:13:48Z

Fair. There's also been a proposal to demote that target (rust-lang/rfcs#3771).

RalfJung · 2025-04-07T17:24:21Z

@bors try

RalfJung · 2025-04-07T17:24:42Z

Oh wait there's conflicts, why did bors not post about that? Odd.

bors · 2025-04-07T17:25:50Z

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

git checkout msvc-align-mitigation (switch to your branch)
git fetch upstream master (retrieve the latest master)
git rebase upstream/master -p (rebase on top of it)
Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
git push self msvc-align-mitigation --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging src/doc/rustc/src/platform-support.md
CONFLICT (content): Merge conflict in src/doc/rustc/src/platform-support.md
Auto-merging compiler/rustc_ty_utils/src/abi.rs
Auto-merging compiler/rustc_target/src/spec/mod.rs
Auto-merging compiler/rustc_target/src/callconv/mod.rs
Auto-merging compiler/rustc_codegen_llvm/src/builder.rs
Automatic merge failed; fix conflicts and then commit the result.

RalfJung · 2025-04-07T17:26:21Z

@bors try

bors · 2025-04-07T17:27:55Z

⌛ Trying commit d9b828f with merge b01413c...

mitigate MSVC alignment issue on x86-32 This implements mitigation for rust-lang#112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems. Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can. Also add an errata note to the platform support page warning users about this known problem. try-job: `i686-msvc*`

bors · 2025-04-07T19:17:27Z

💔 Test failed - checks-actions

…32-msvc targets also mention the MSVC alignment issue in platform-support.md

RalfJung · 2025-04-07T21:31:16Z

@bors try

mitigate MSVC alignment issue on x86-32 This implements mitigation for rust-lang#112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems. Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can. Also add an errata note to the platform support page warning users about this known problem. try-job: `i686-msvc*`

bors · 2025-04-07T21:32:28Z

⌛ Trying commit e702f96 with merge 27ef8fe...

bors · 2025-04-08T00:21:10Z

☀️ Try build successful - checks-actions
Build commit: 27ef8fe (27ef8fe238fd8ed3348e55d4d58f946056e636d8)

RalfJung · 2025-04-08T06:21:53Z

All right this should be @rustbot ready now.

rustbot assigned oli-obk Apr 2, 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 Apr 2, 2025

RalfJung commented Apr 2, 2025

View reviewed changes

ChrisDenton reviewed Apr 2, 2025

View reviewed changes

compiler/rustc_target/src/spec/mod.rs Outdated Show resolved Hide resolved

RalfJung force-pushed the msvc-align-mitigation branch from ce44d17 to 66f7993 Compare April 2, 2025 15:44

beetrees reviewed Apr 2, 2025

View reviewed changes

compiler/rustc_codegen_llvm/src/builder.rs Outdated Show resolved Hide resolved

RalfJung force-pushed the msvc-align-mitigation branch from 66f7993 to ca29777 Compare April 3, 2025 15:48

This comment has been minimized.

Sign in to view

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-review Status: Awaiting review from the assignee but also interested parties. labels Apr 3, 2025

RalfJung force-pushed the msvc-align-mitigation branch from ca29777 to d4ce381 Compare April 4, 2025 13:14

saethlin reviewed Apr 4, 2025

View reviewed changes

compiler/rustc_mir_transform/src/check_alignment.rs Outdated Show resolved Hide resolved

RalfJung force-pushed the msvc-align-mitigation branch from 178790f to df69e5d Compare April 4, 2025 16:07

RalfJung commented Apr 4, 2025

View reviewed changes

tests/codegen/align-struct.rs Outdated Show resolved Hide resolved

beetrees reviewed Apr 4, 2025

View reviewed changes

src/doc/rustc/src/platform-support.md Show resolved Hide resolved

RalfJung force-pushed the msvc-align-mitigation branch from df69e5d to 82ab25c Compare April 7, 2025 15:18

RalfJung force-pushed the msvc-align-mitigation branch from 82ab25c to d9b828f Compare April 7, 2025 17:26

This comment has been minimized.

Sign in to view

RalfJung added 2 commits April 7, 2025 23:30

mitigate MSVC unsoundness by not emitting alignment attributes on win…

2678d04

…32-msvc targets also mention the MSVC alignment issue in platform-support.md

check_align: we can still check low alignments on MSVC

e702f96

RalfJung force-pushed the msvc-align-mitigation branch from d9b828f to e702f96 Compare April 7, 2025 21:31

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 Apr 8, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

mitigate MSVC alignment issue on x86-32 #139261

mitigate MSVC alignment issue on x86-32 #139261

RalfJung commented Apr 2, 2025 •

edited

Loading

rustbot commented Apr 2, 2025

rustbot commented Apr 2, 2025

RalfJung Apr 2, 2025

ChrisDenton Apr 2, 2025

RalfJung Apr 2, 2025

ChrisDenton Apr 2, 2025

RalfJung commented Apr 2, 2025

bors commented Apr 2, 2025

beetrees commented Apr 2, 2025 •

edited

Loading

RalfJung commented Apr 2, 2025

RalfJung commented Apr 3, 2025

bors commented Apr 3, 2025

This comment has been minimized.

bors commented Apr 3, 2025

RalfJung commented Apr 4, 2025

RalfJung commented Apr 4, 2025

bors commented Apr 4, 2025

bors commented Apr 4, 2025

beetrees commented Apr 4, 2025

RalfJung commented Apr 4, 2025

beetrees commented Apr 4, 2025

RalfJung commented Apr 5, 2025 •

edited

Loading

RalfJung commented Apr 7, 2025

RalfJung commented Apr 7, 2025

bors commented Apr 7, 2025

RalfJung commented Apr 7, 2025

bors commented Apr 7, 2025

This comment has been minimized.

This comment has been minimized.

bors commented Apr 7, 2025

RalfJung commented Apr 7, 2025

bors commented Apr 7, 2025

bors commented Apr 8, 2025

RalfJung commented Apr 8, 2025

mitigate MSVC alignment issue on x86-32 #139261

Are you sure you want to change the base?

mitigate MSVC alignment issue on x86-32 #139261

Conversation

RalfJung commented Apr 2, 2025 • edited Loading

rustbot commented Apr 2, 2025

rustbot commented Apr 2, 2025

RalfJung Apr 2, 2025

Choose a reason for hiding this comment

ChrisDenton Apr 2, 2025

Choose a reason for hiding this comment

RalfJung Apr 2, 2025

Choose a reason for hiding this comment

ChrisDenton Apr 2, 2025

Choose a reason for hiding this comment

RalfJung commented Apr 2, 2025

bors commented Apr 2, 2025

beetrees commented Apr 2, 2025 • edited Loading

RalfJung commented Apr 2, 2025

RalfJung commented Apr 3, 2025

bors commented Apr 3, 2025

This comment has been minimized.

bors commented Apr 3, 2025

RalfJung commented Apr 4, 2025

RalfJung commented Apr 4, 2025

bors commented Apr 4, 2025

bors commented Apr 4, 2025

beetrees commented Apr 4, 2025

RalfJung commented Apr 4, 2025

beetrees commented Apr 4, 2025

RalfJung commented Apr 5, 2025 • edited Loading

RalfJung commented Apr 7, 2025

RalfJung commented Apr 7, 2025

bors commented Apr 7, 2025

RalfJung commented Apr 7, 2025

bors commented Apr 7, 2025

This comment has been minimized.

This comment has been minimized.

bors commented Apr 7, 2025

RalfJung commented Apr 7, 2025

bors commented Apr 7, 2025

bors commented Apr 8, 2025

RalfJung commented Apr 8, 2025

RalfJung commented Apr 2, 2025 •

edited

Loading

beetrees commented Apr 2, 2025 •

edited

Loading

RalfJung commented Apr 5, 2025 •

edited

Loading