Nightly 2025-02-03 to 2025-02-04: "Error loading target specification: target feature sse2 is required by the ABI but gets disabled in target spec" with JSON target specification

[fmckeogh]

Code

I have the following target JSON (same as x86_64-unknown-none but with dynamic linking enabled) for a kernel (https://github.com/avisi-group/borg/tree/main/brig):

{
  "arch": "x86_64",
  "code-model": "kernel",
  "cpu": "x86-64",
  "crt-objects-fallback": "false",
  "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128",
  "disable-redzone": true,
  "features": "-mmx,-sse,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-avx,-avx2,+soft-float",
  "is-builtin": false,
  "dynamic-linking": true,
  "linker": "rust-lld",
  "linker-flavor": "gnu-lld",
  "llvm-target": "x86_64-unknown-none-elf",
  "max-atomic-width": 64,
  "metadata": {
    "description": null,
    "host_tools": null,
    "std": null,
    "tier": null
  },
  "panic-strategy": "abort",
  "plt-by-default": false,
  "position-independent-executables": true,
  "relro-level": "full",
  "stack-probes": {
    "kind": "inline"
  },
  "static-position-independent-executables": true,
  "supported-sanitizers": [
    "kcfi",
    "kernel-address"
  ],
  "target-pointer-width": "64"
}

In nightlies earlier and including 2025-02-03 this compiles correctly. Today, nightly-2025-02-04 gives the following error:

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/home/fm208/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/rustc - --crate-name ___ --print=file-names -C force-frame-pointers=yes -C link-arg=-z -C link-arg=nostar)
  --- stderr
  error: Error loading target specification: target feature `sse2` is required by the ABI but gets disabled in target spec. Run `rustc --print target-list` for a list of built-in targets

I believe this might be related to #134794, but I am not sure what the fix would be for my code?

Version it worked on

It most recently worked on: nightly-2025-02-03

Version with regression

I don't understand the following, however. When I run the 2025-02-04 binary, it reports the same commit hash and LLVM version as 2025-02-03 but I'm definitely experiencing different behavior when I switch between them. Either with rust-toolchain.toml or cargo +<toolchain>.

rustc --version --verbose:

$ ~/.rustup/toolchains/nightly-2025-02-04-x86_64-unknown-linux-gnu/bin/rustc  --version --verbose
rustc 1.86.0-nightly (f027438f8 2025-02-03)
binary: rustc
commit-hash: f027438f8bc6b747528dca8b8de13043544d7238
commit-date: 2025-02-03
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.7

[jieyouxu]

I believe this is not a regression and is intentional as introduced in #134794, but cc @RalfJung

[RalfJung]

This is caused by #136146. x86 softfloat target specs need to add

"rustc-abi": "x86-softfloat",

to explicitly declare the intended ABI to the compiler. This is part of a larger effort to be more explicit and consistent and sound around the way we handle ABI variants and their interaction with target features.

[fmckeogh]

@jieyouxu @RalfJung My apologies, thank you!

[RalfJung]

No worries. :)

In fact, let's leave this issue open for a few days; I assume more people will run into this.

[lqd]

Could that be a default in the target spec deserialization procedure? (e.g., if there's no rustc-abi specified and there's a +soft-float feature)

[RalfJung]

No, I don't think we want to infer the ABI from the target features. The entire point is to make ABI choices more explicit.

[Hello-world150]

#136544 (comment)

Thank you very much!! I can solve this problem easily!!

[Hello-world150]

I've encountered something strange. I added one line as this comment said. OK, it ran successfully. But when I run it again, it said "error: Error loading target specification: target feature soft-float is incompatible with the ABI but gets enabled in target spec. Run rustc --print target-list for a list of built-in targets", like the beginning. I am sure that my target file added "rustc-abi": "x86-softfloat",. What happened ???

[RalfJung]

I don't know what could be causing a different result on the 2nd run -- that might be caused by some of the tooling around rustc; rustc itself doesn't do any caching here AFAIK.