Unrolled build for rust-lang#134609

Rollup merge of rust-lang#134609 - tbu-:pr_win7_gnu, r=davidtwco

Add new `{x86_64,i686}-win7-windows-gnu` targets

These are in symmetry with `{x86_64,i686}-win7-windows-msvc`.

> ## Tier 3 target policy
>
> At this tier, the Rust project provides no official support for a target, so we
> place minimal requirements on the introduction of targets.
>
> A proposed new tier 3 target must be reviewed and approved by a member of the
> compiler team based on these requirements. The reviewer may choose to gauge
> broader compiler team consensus via a [Major Change Proposal (MCP)][https://forge.rust-lang.org/compiler/mcp.html].
>
> A proposed target or target-specific patch that substantially changes code
> shared with other targets (not just target-specific code) must be reviewed and
> approved by the appropriate team for that shared code before acceptance.
>
> - A tier 3 target must have a designated developer or developers (the "target
>   maintainers") on record to be CCed when issues arise regarding the target.
>   (The mechanism to track and CC such developers may evolve over time.)

This is me, `@tbu-` on github.

> - Targets must use naming consistent with any existing targets; for instance, a
>   target for the same CPU or OS as an existing Rust target should use the same
>   name for that CPU or OS. Targets should normally use the same names and
>   naming conventions as used elsewhere in the broader ecosystem beyond Rust
>   (such as in other toolchains), unless they have a very good reason to
>   diverge. Changing the name of a target can be highly disruptive, especially
>   once the target reaches a higher tier, so getting the name right is important
>   even for a tier 3 target.
>   - Target names should not introduce undue confusion or ambiguity unless
>     absolutely necessary to maintain ecosystem compatibility. For example, if
>     the name of the target makes people extremely likely to form incorrect
>     beliefs about what it targets, the name should be changed or augmented to
>     disambiguate it.
>   - If possible, use only letters, numbers, dashes and underscores for the name.
>     Periods (`.`) are known to cause issues in Cargo.

Consistent with `{x86_64,i686}-win7-windows-msvc`, see also rust-lang#118150.

> - Tier 3 targets may have unusual requirements to build or use, but must not
>   create legal issues or impose onerous legal terms for the Rust project or for
>   Rust developers or users.
>   - The target must not introduce license incompatibilities.
>   - Anything added to the Rust repository must be under the standard Rust
>     license (`MIT OR Apache-2.0`).
>   - The target must not cause the Rust tools or libraries built for any other
>     host (even when supporting cross-compilation to the target) to depend
>     on any new dependency less permissive than the Rust licensing policy. This
>     applies whether the dependency is a Rust crate that would require adding
>     new license exceptions (as specified by the `tidy` tool in the
>     rust-lang/rust repository), or whether the dependency is a native library
>     or binary. In other words, the introduction of the target must not cause a
>     user installing or running a version of Rust or the Rust tools to be
>     subject to any new license requirements.
>   - Compiling, linking, and emitting functional binaries, libraries, or other
>     code for the target (whether hosted on the target itself or cross-compiling
>     from another target) must not depend on proprietary (non-FOSS) libraries.
>     Host tools built for the target itself may depend on the ordinary runtime
>     libraries supplied by the platform and commonly used by other applications
>     built for the target, but those libraries must not be required for code
>     generation for the target; cross-compilation to the target must not require
>     such libraries at all. For instance, `rustc` built for the target may
>     depend on a common proprietary C runtime library or console output library,
>     but must not depend on a proprietary code generation library or code
>     optimization library. Rust's license permits such combinations, but the
>     Rust project has no interest in maintaining such combinations within the
>     scope of Rust itself, even at tier 3.
>   - "onerous" here is an intentionally subjective term. At a minimum, "onerous"
>     legal/licensing terms include but are *not* limited to: non-disclosure
>     requirements, non-compete requirements, contributor license agreements
>     (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms,
>     requirements conditional on the employer or employment of any particular
>     Rust developers, revocable terms, any requirements that create liability
>     for the Rust project or its developers or users, or any requirements that
>     adversely affect the livelihood or prospects of the Rust project or its
>     developers or users.

AFAICT, it's the same legal situation as the tier 1 `{x86_64,i686}-pc-windows-gnu`.

> - Neither this policy nor any decisions made regarding targets shall create any
>   binding agreement or estoppel by any party. If any member of an approving
>   Rust team serves as one of the maintainers of a target, or has any legal or
>   employment requirement (explicit or implicit) that might affect their
>   decisions regarding a target, they must recuse themselves from any approval
>   decisions regarding the target's tier status, though they may otherwise
>   participate in discussions.
>   - This requirement does not prevent part or all of this policy from being
>     cited in an explicit contract or work agreement (e.g. to implement or
>     maintain support for a target). This requirement exists to ensure that a
>     developer or team responsible for reviewing and approving a target does not
>     face any legal threats or obligations that would prevent them from freely
>     exercising their judgment in such approval, even if such judgment involves
>     subjective matters or goes beyond the letter of these requirements.

Understood.

> - Tier 3 targets should attempt to implement as much of the standard libraries
>   as possible and appropriate (`core` for most targets, `alloc` for targets
>   that can support dynamic memory allocation, `std` for targets with an
>   operating system or equivalent layer of system-provided functionality), but
>   may leave some code unimplemented (either unavailable or stubbed out as
>   appropriate), whether because the target makes it impossible to implement or
>   challenging to implement. The authors of pull requests are not obligated to
>   avoid calling any portions of the standard library on the basis of a tier 3
>   target not implementing those portions.

This target supports the whole libstd surface, since it's essentially reusing all of the x86_64-pc-windows-gnu target. Understood.

> - The target must provide documentation for the Rust community explaining how
>   to build for the target, using cross-compilation if possible. If the target
>   supports running binaries, or running tests (even if they do not pass), the
>   documentation must explain how to run such binaries or tests for the target,
>   using emulation if possible or dedicated hardware if necessary.

I tried to write some documentation on that.

> - Tier 3 targets must not impose burden on the authors of pull requests, or
>   other developers in the community, to maintain the target. In particular,
>   do not post comments (automated or manual) on a PR that derail or suggest a
>   block on the PR based on a tier 3 target. Do not send automated messages or
>   notifications (via any medium, including via ``@`)` to a PR author or others
>   involved with a PR regarding a tier 3 target, unless they have opted into
>   such messages.
>   - Backlinks such as those generated by the issue/PR tracker when linking to
>     an issue or PR are not considered a violation of this policy, within
>     reason. However, such messages (even on a separate repository) must not
>     generate notifications to anyone involved with a PR who has not requested
>     such notifications.

Understood.

> - Patches adding or updating tier 3 targets must not break any existing tier 2
>   or tier 1 target, and must not knowingly break another tier 3 target without
>   approval of either the compiler team or the maintainers of the other tier 3
>   target.
>   - In particular, this may come up when working on closely related targets,
>     such as variations of the same architecture with different features. Avoid
>     introducing unconditional uses of features that another variation of the
>     target may not have; use conditional compilation or runtime detection, as
>     appropriate, to let each target run code supported by that target.
> - Tier 3 targets must be able to produce assembly using at least one of
>   rustc's supported backends from any host target. (Having support in a fork
>   of the backend is not sufficient, it must be upstream.)

Understood.

> If a tier 3 target stops meeting these requirements, or the target maintainers
> no longer have interest or time, or the target shows no signs of activity and
> has not built for some time, or removing the target would improve the quality
> of the Rust codebase, we may post a PR to remove it; any such PR will be CCed
> to the target maintainers (and potentially other people who have previously
> worked on the target), to check potential interest in improving the situation.
>

Understood.

r? compiler-team

Author: rust-timer

compiler/rustc_target/src/spec/mod.rs

@@ -1812,9 +1812,11 @@ supported_targets! {
     ("aarch64-unknown-illumos", aarch64_unknown_illumos),
 
     ("x86_64-pc-windows-gnu", x86_64_pc_windows_gnu),
+    ("x86_64-uwp-windows-gnu", x86_64_uwp_windows_gnu),
+    ("x86_64-win7-windows-gnu", x86_64_win7_windows_gnu),
     ("i686-pc-windows-gnu", i686_pc_windows_gnu),
     ("i686-uwp-windows-gnu", i686_uwp_windows_gnu),
-    ("x86_64-uwp-windows-gnu", x86_64_uwp_windows_gnu),
+    ("i686-win7-windows-gnu", i686_win7_windows_gnu),
 
     ("aarch64-pc-windows-gnullvm", aarch64_pc_windows_gnullvm),
     ("i686-pc-windows-gnullvm", i686_pc_windows_gnullvm),

compiler/rustc_target/src/spec/targets/i686_win7_windows_gnu.rs

@@ -0,0 +1,35 @@
+use crate::spec::{Cc, FramePointer, LinkerFlavor, Lld, Target, base};
+
+pub(crate) fn target() -> Target {
+    let mut base = base::windows_gnu::opts();
+    base.vendor = "win7".into();
+    base.cpu = "pentium4".into();
+    base.max_atomic_width = Some(64);
+    base.frame_pointer = FramePointer::Always; // Required for backtraces
+    base.linker = Some("i686-w64-mingw32-gcc".into());
+
+    // Mark all dynamic libraries and executables as compatible with the larger 4GiB address
+    // space available to x86 Windows binaries on x86_64.
+    base.add_pre_link_args(LinkerFlavor::Gnu(Cc::No, Lld::No), &[
+        "-m",
+        "i386pe",
+        "--large-address-aware",
+    ]);
+    base.add_pre_link_args(LinkerFlavor::Gnu(Cc::Yes, Lld::No), &["-Wl,--large-address-aware"]);
+
+    Target {
+        llvm_target: "i686-pc-windows-gnu".into(),
+        metadata: crate::spec::TargetMetadata {
+            description: Some("32-bit MinGW (Windows 7+)".into()),
+            tier: Some(3),
+            host_tools: Some(false),
+            std: Some(true),
+        },
+        pointer_width: 32,
+        data_layout: "e-m:x-p:32:32-p270:32:32-p271:32:32-p272:64:64-\
+            i64:64-i128:128-f80:32-n8:16:32-a:0:32-S32"
+            .into(),
+        arch: "x86".into(),
+        options: base,
+    }
+}

compiler/rustc_target/src/spec/targets/x86_64_win7_windows_gnu.rs

@@ -0,0 +1,32 @@
+use crate::spec::{Cc, LinkerFlavor, Lld, Target, base};
+
+pub(crate) fn target() -> Target {
+    let mut base = base::windows_gnu::opts();
+    base.vendor = "win7".into();
+    base.cpu = "x86-64".into();
+    base.plt_by_default = false;
+    // Use high-entropy 64 bit address space for ASLR
+    base.add_pre_link_args(LinkerFlavor::Gnu(Cc::No, Lld::No), &[
+        "-m",
+        "i386pep",
+        "--high-entropy-va",
+    ]);
+    base.add_pre_link_args(LinkerFlavor::Gnu(Cc::Yes, Lld::No), &["-m64", "-Wl,--high-entropy-va"]);
+    base.max_atomic_width = Some(64);
+    base.linker = Some("x86_64-w64-mingw32-gcc".into());
+
+    Target {
+        llvm_target: "x86_64-pc-windows-gnu".into(),
+        metadata: crate::spec::TargetMetadata {
+            description: Some("64-bit MinGW (Windows 7+)".into()),
+            tier: Some(3),
+            host_tools: Some(false),
+            std: Some(true),
+        },
+        pointer_width: 64,
+        data_layout:
+            "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128".into(),
+        arch: "x86_64".into(),
+        options: base,
+    }
+}

src/doc/rustc/src/SUMMARY.md

@@ -70,8 +70,8 @@
     - [powerpc-unknown-linux-muslspe](platform-support/powerpc-unknown-linux-muslspe.md)
     - [powerpc64-ibm-aix](platform-support/aix.md)
     - [powerpc64le-unknown-linux-musl](platform-support/powerpc64le-unknown-linux-musl.md)
-    - [riscv32e*-unknown-none-elf](platform-support/riscv32e-unknown-none-elf.md)
-    - [riscv32i*-unknown-none-elf](platform-support/riscv32-unknown-none-elf.md)
+    - [riscv32e\*-unknown-none-elf](platform-support/riscv32e-unknown-none-elf.md)
+    - [riscv32i\*-unknown-none-elf](platform-support/riscv32-unknown-none-elf.md)
     - [riscv32im-risc0-zkvm-elf](platform-support/riscv32im-risc0-zkvm-elf.md)
     - [riscv32imac-unknown-xous-elf](platform-support/riscv32imac-unknown-xous-elf.md)
     - [riscv64gc-unknown-linux-gnu](platform-support/riscv64gc-unknown-linux-gnu.md)
@@ -80,14 +80,14 @@
     - [s390x-unknown-linux-musl](platform-support/s390x-unknown-linux-musl.md)
     - [sparc-unknown-none-elf](./platform-support/sparc-unknown-none-elf.md)
     - [sparcv9-sun-solaris](platform-support/solaris.md)
-    - [*-pc-windows-gnullvm](platform-support/pc-windows-gnullvm.md)
+    - [\*-pc-windows-gnullvm](platform-support/pc-windows-gnullvm.md)
     - [\*-nto-qnx-\*](platform-support/nto-qnx.md)
-    - [*-unikraft-linux-musl](platform-support/unikraft-linux-musl.md)
-    - [*-unknown-hermit](platform-support/hermit.md)
-    - [*-unknown-freebsd](platform-support/freebsd.md)
+    - [\*-unikraft-linux-musl](platform-support/unikraft-linux-musl.md)
+    - [\*-unknown-hermit](platform-support/hermit.md)
+    - [\*-unknown-freebsd](platform-support/freebsd.md)
     - [\*-unknown-netbsd\*](platform-support/netbsd.md)
-    - [*-unknown-openbsd](platform-support/openbsd.md)
-    - [*-unknown-redox](platform-support/redox.md)
+    - [\*-unknown-openbsd](platform-support/openbsd.md)
+    - [\*-unknown-redox](platform-support/redox.md)
     - [\*-unknown-uefi](platform-support/unknown-uefi.md)
     - [\*-uwp-windows-msvc](platform-support/uwp-windows-msvc.md)
     - [\*-wrs-vxworks](platform-support/vxworks.md)
@@ -98,13 +98,14 @@
     - [wasm32-unknown-unknown](platform-support/wasm32-unknown-unknown.md)
     - [wasm32v1-none](platform-support/wasm32v1-none.md)
     - [wasm64-unknown-unknown](platform-support/wasm64-unknown-unknown.md)
+    - [\*-win7-windows-gnu](platform-support/win7-windows-gnu.md)
     - [\*-win7-windows-msvc](platform-support/win7-windows-msvc.md)
     - [x86_64-fortanix-unknown-sgx](platform-support/x86_64-fortanix-unknown-sgx.md)
     - [x86_64-pc-solaris](platform-support/solaris.md)
     - [x86_64-unknown-linux-none.md](platform-support/x86_64-unknown-linux-none.md)
     - [x86_64-unknown-none](platform-support/x86_64-unknown-none.md)
     - [xtensa-\*-none-elf](platform-support/xtensa.md)
-    - [*-nuttx-\*](platform-support/nuttx.md)
+    - [\*-nuttx-\*](platform-support/nuttx.md)
 - [Targets](targets/index.md)
     - [Built-in Targets](targets/built-in.md)
     - [Custom Targets](targets/custom.md)

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

@@ -313,6 +313,7 @@ target | std | host | notes
 [`i686-unknown-redox`](platform-support/redox.md) | ✓ |  | i686 Redox OS
 `i686-uwp-windows-gnu` | ✓ |  | [^x86_32-floats-return-ABI]
 [`i686-uwp-windows-msvc`](platform-support/uwp-windows-msvc.md) | ✓ |  | [^x86_32-floats-return-ABI]
+[`i686-win7-windows-gnu`](platform-support/win7-windows-gnu.md) | ✓ |   | 32-bit Windows 7 support [^x86_32-floats-return-ABI]
 [`i686-win7-windows-msvc`](platform-support/win7-windows-msvc.md) | ✓ |   | 32-bit Windows 7 support [^x86_32-floats-return-ABI]
 [`i686-wrs-vxworks`](platform-support/vxworks.md) | ✓ |  | [^x86_32-floats-return-ABI]
 [`loongarch64-unknown-linux-ohos`](platform-support/openharmony.md) | ✓ |   | LoongArch64 OpenHarmony
@@ -410,6 +411,7 @@ target | std | host | notes
 [`x86_64-unknown-trusty`](platform-support/trusty.md) | ? |  |
 `x86_64-uwp-windows-gnu` | ✓ |  |
 [`x86_64-uwp-windows-msvc`](platform-support/uwp-windows-msvc.md) | ✓ |  |
+[`x86_64-win7-windows-gnu`](platform-support/win7-windows-gnu.md) | ✓ |   | 64-bit Windows 7 support
 [`x86_64-win7-windows-msvc`](platform-support/win7-windows-msvc.md) | ✓ |   | 64-bit Windows 7 support
 [`x86_64-wrs-vxworks`](platform-support/vxworks.md) | ✓ |  |
 [`x86_64h-apple-darwin`](platform-support/x86_64h-apple-darwin.md) | ✓ | ✓ | macOS with late-gen Intel (at least Haswell)

src/doc/rustc/src/platform-support/win7-windows-gnu.md

@@ -0,0 +1,48 @@
+# \*-win7-windows-gnu
+
+**Tier: 3**
+
+Windows targets continuing support of Windows 7.
+
+Target triples:
+- `i686-win7-windows-gnu`
+- `x86_64-win7-windows-gnu`
+
+## Target maintainers
+
+- @tbu-
+
+## Requirements
+
+This target supports all of core, alloc, std and test. Host
+tools may also work, though those are not currently tested.
+
+Those targets follow Windows calling convention for extern "C".
+
+Like any other Windows target, the created binaries are in PE format.
+
+## Building the target
+
+You can build Rust with support for the targets by adding it to the target list in config.toml:
+
+```toml
+[build]
+build-stage = 1
+target = ["x86_64-win7-windows-gnu"]
+```
+
+## Building Rust programs
+
+Rust does not ship pre-compiled artifacts for this target. To compile for this
+target, you will either need to build Rust with the target enabled (see
+"Building the target" above), or build your own copy by using `build-std` or
+similar.
+
+## Testing
+
+Created binaries work fine on Windows or Wine using native hardware. Remote
+testing is possible using the `remote-test-server` described [here](https://rustc-dev-guide.rust-lang.org/tests/running.html#running-tests-on-a-remote-machine).
+
+## Cross-compilation toolchains and C code
+
+Compatible C code can be built with gcc's `{i686,x86_64}-w64-mingw32-gcc`.

src/doc/rustc/src/platform-support/win7-windows-msvc.md

@@ -1,8 +1,12 @@
-# *-win7-windows-msvc
+# \*-win7-windows-msvc
 
 **Tier: 3**
 
-Windows targets continuing support of windows7.
+Windows targets continuing support of Windows 7.
+
+Target triples:
+- `i686-win7-windows-msvc`
+- `x86_64-win7-windows-msvc`
 
 ## Target maintainers
 

tests/assembly/targets/targets-pe.rs

@@ -39,6 +39,9 @@
 //@ revisions: i686_uwp_windows_gnu
 //@ [i686_uwp_windows_gnu] compile-flags: --target i686-uwp-windows-gnu
 //@ [i686_uwp_windows_gnu] needs-llvm-components: x86
+//@ revisions: i686_win7_windows_gnu
+//@ [i686_win7_windows_gnu] compile-flags: --target i686-win7-windows-gnu
+//@ [i686_win7_windows_gnu] needs-llvm-components: x86
 //@ revisions: i686_unknown_uefi
 //@ [i686_unknown_uefi] compile-flags: --target i686-unknown-uefi
 //@ [i686_unknown_uefi] needs-llvm-components: x86
@@ -72,6 +75,9 @@
 //@ revisions: x86_64_uwp_windows_gnu
 //@ [x86_64_uwp_windows_gnu] compile-flags: --target x86_64-uwp-windows-gnu
 //@ [x86_64_uwp_windows_gnu] needs-llvm-components: x86
+//@ revisions: x86_64_win7_windows_gnu
+//@ [x86_64_win7_windows_gnu] compile-flags: --target x86_64-win7-windows-gnu
+//@ [x86_64_win7_windows_gnu] needs-llvm-components: x86
 //@ revisions: x86_64_uwp_windows_msvc
 //@ [x86_64_uwp_windows_msvc] compile-flags: --target x86_64-uwp-windows-msvc
 //@ [x86_64_uwp_windows_msvc] needs-llvm-components: x86