RFC: Demote i686-pc-windows-gnu to Tier 2 #3771
Conversation
Co-authored-by: Jubilee Young <workingjubilee@gmail.com>
Noratrieb
force-pushed
the
i686-pc-windows-gnu
branch
from
f8dfc48 to
00b04e1
Compare
Noratrieb
added
T-compiler
| While some of these issues apply to all GNU-based targets, 32-bit x86 seems to be especially affected. | ||
| And when a 32-bit Windows GNU issue comes up, contributors rarely actually investigate it, because it is such a complex and nonstandard environment compared to 64-bit Windows GNU, which is a lot easier to set up and work with. |
There was a problem hiding this comment.
Remark: one such example: rust-lang/rust#136795
| > The target maintainer team must include at least 3 developers. | ||
|
|
||
| This is not the case at all. There is currently no maintainer team. | ||
| Though we should note that this is currently also true for many other Tier 1 targets, as this is a new rule not upheld everywhere yet. | ||
| But experience tells that it is highly unlikely that 3 maintainers for 32 bit Windows GNU will be found. |
There was a problem hiding this comment.
Remark: and I think it's arguably misleading to say (or "promise", for that matter) i686-pc-windows-gnu is a Tier 1 target when it does not really receive Tier 1 maintenance support IMHO.
|
|
||
| ## Conclusion | ||
|
|
||
| Given the usage count and lack of maintenance leading to more than one requirement not being fulfilled, it becomes clear that `i686-pc-windows-gnu` is not worthy of being a Tier 1 target and is already getting much worse support than expected from a Tier 1 target. |
There was a problem hiding this comment.
Remark: arguably, it also imposes a maintenance burden on compiler contributors because if a test fails on just i686-mingw (32-bit windows-gnu) but not 64-bit windows-{msvc,gnu} it's very annoying to bless that.
| `x86_64-pc-windows-gnu` will remain a Tier 1 target after this RFC. | ||
| While its popularity is more aligned with Tier 1, it suffers from the same lack of maintenance (but to a lesser degree) as its 32-bit cousin. | ||
| It may be demoted as well in the future. |
There was a problem hiding this comment.
Remark: at least the 64-bit windows-gnu is more accessible as a host target, unlike the 32-bit windows-gnu.
There was a problem hiding this comment.
if you want to cross-compile from linux to windows, the 64-bit windows-gnu (or gnullvm) target is the best way to do that, so I expect it to stay around a lot longer. we'd probably want to add an arm gnu target too at some point.
There was a problem hiding this comment.
I expect that we would have an aarch64-pc-windows-gnullvm or whatever target instead (though that's functionally equivalent for practical use-cases).
There was a problem hiding this comment.
This discussion is drifting away from the culprit, but I don't see value in ARM targets (32-bit).
AArch64 is already there as a cross compilation target (gnullvm only until GNU catches up), and once LLVM 20 goes live, I'll try to start MCP for promoting 64-bit gnullvm targets to hosts.
There was a problem hiding this comment.
AArch64 is already there as a cross compilation target (gnullvm only until GNU catches up), and once LLVM 20 goes live, I'll try to start MCP for promoting 64-bit gnullvm targets to hosts.
nice! I had meant aarch64, but iirc windows doesn't call it that for some reason...
|
I addressed some of the feedback I thought was worth putting into the RFC text itself. The target tier policy says
It does not say what teams should be involved in the demotion of a tier 1 target, but I leaned on the side of caution and chose to include compiler and release. I guess release can judge the non-viability and lack of value of supporting the target :D I don't expect this to be controversial, so |
|
Team member @Noratrieb has proposed to merge this. The next step is review by the rest of the tagged team members:
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. |
rfcbot
added
proposed-final-comment-period
| That demotion will not need an RFC. | ||
|
|
||
| The `*-windows-gnullvm` targets, which are based on LLVM instead of GNU tools, may see increased maintenance and popularity in the future, replacing the `*-windows-gnu` targets. | ||
| But it seems unlikely that `i686-pc-windows-gnullvm` would ever acquire Tier 1 status. |
There was a problem hiding this comment.
| But it seems unlikely that `i686-pc-windows-gnullvm` would ever acquire Tier 1 status. | |
| (However, the 32-bit `i686-pc-windows-gnullvm` will not attain Tier 1 status either, for multiple reasons including the inability to link large binaries such as `rustc`.) |
There was a problem hiding this comment.
I can resolve the uncertainty; it is outright impossible.
LLVM uses memory mapping for many I/O operations. On 32-bit Windows, it cannot even host itself due to insufficient address space.
There was a problem hiding this comment.
@mati865 Is that an issue with the compiler or with the linker? (Would it work if linked with a different linker?)
In any case, thanks for the clarification. I'll edit the suggestion.
There was a problem hiding this comment.
@joshtriplett LLD hit a 32-bit mmap issue long ago, and upstream added a workaround using non-memory-mapped I/O on 32-bits. IIRC this time it was LLVM that encountered this problem while handling archives, but my memory may be faulty.
After reconsidering, I would say it is impossible without (possibly significant) changes to LLVM.
Edit: also see rust-lang/rust#131786
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
|
Thanks everyone! I have created rust-lang/rust#138422 to track the necessary steps. |
Rendered