Drop tier 2 `i686-pc-windows-gnu` host tools

[mati865]

Proposal

I propose removing host tools support for i686-pc-windows-gnu target. This target is currently tier 2 with host tools and if this MCP is accepted it'd become tier 2 std only.

The issues

Recently we've encountered major difficulties with 32-bit Windows host tools CI jobs, that could be summarised as "32-bit address space was reasonable two decades ago, but we are no longer living two decades ago". Specifically I mean:

• dist-i686-msvc fails with STATUS_NO_MEMORY rust#159076 that was only tested with i686-pc-windows-msvc (only because we hit it first, due to MSVC CI job being faster), but I expect to also hit on 32-bit windows-gnu. Separately to this MCP we are also eyeing on dropping host tools for 32-bit MSVC.
• GCC's OOM when building upgrade LLVM 23 (still a draft PR), nikic was able to work around it by disabling RISC-V target in LLVM for this target only.

That is a clear violation of tier 2 host tools target requirements:

• The host tools must build and run reliably in CI (for all components that Rust’s CI considers mandatory), though they may or may not pass tests.

• The host tools must provide a substantively similar experience as on other targets, subject to reasonable target limitations.

While the first issue was partially caused by our own changes (32-bit Windows targets made only made it a bigger deal), GCC going going beyond 32-bit address space during LLVM build is something that we cannot reasonably control and it will only get worse.

Target popularity

Numbers stolen borrowed from 32-bit MSVC demotion RFC draft:

Download counts for the host toolchain and std were extracted from the public dashboard covering the period from 2026-06-01 to 2026-06-30.

Name	Tier	rustc download count	std download count
i686-pc-windows-msvc	1	436.26k	6.83M
x86_64-pc-windows-msvc	1	34.65M	21.05M
x86_64-pc-windows-gnu	1	1.32M	8.64M
aarch64-pc-windows-msvc	2	5.18M	6.96M
i686-pc-windows-gnu	2	72.09k	3.62M

This evidence clearly shows i686-pc-windows-gnu is super niche as a host target and mostly used as the cross-compilation target, reducing the impact of this change.

Previous changes to this target

This target has been demoted from tier 1 with host tools, down to tier 2 with host tools last year: https://github.com/rust-lang/rfcs/blob/master/text/3771-demote-i686-pc-windows-gnu.md

I'll quote relevant sentences from that RFC which I think make this MCP sufficient:

• If necessary, further demotions (for example removing host tools) will not require RFCs, but go through a simpler MCP instead.

• The maintenance requirement violation can be solved by multiple people stepping up to maintain this target. This has not happened so far.

It's been a year and still nobody stood up for this target (readers of this MCP, this is your last chance to stand up). I believe it'll be near to impossible to find people would work on this target on the following sides: Rust, LLVM, GCC (so it stops going OOM at the very least), and Binutils.

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them here. You can put your own name here if you are planning to mentor the work.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[jieyouxu]

@rust-rfcbot fcp merge

[rust-rfcbot]

@jieyouxu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Mark-Simulacrum
• @TaKO8Ki
• @davidtwco
• @estebank
• @jdonszelmann
• @jieyouxu
• @nnethercote
• @oli-obk
• @petrochenkov
• @spastorino
• @wesleywiser

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.