Compiler builtins missing f16/f128 symbols

[tgross35]

Reported by @TimNN here:

I think something in this PR might be broken with regard to whether the f16/f128 builtins are being generated.

I have downloaded https://ci-artifacts.rust-lang.org/rustc-builds/80d8270d8488957f62fbf0df7a19dfe596be92ac/rust-std-nightly-x86_64-unknown-linux-gnu.tar.xz

And ran

llvm-nm ./rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-7586cb84705120bb.rlib | grep __extend
./rust-std-nightly-x86_64-unknown-linux-gnu/rust-std-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-7586cb84705120bb.rlib:lib.rmeta: no symbols
0000000000000000 T _ZN17compiler_builtins5float6extend13__extendsfdf217hc5379a65d797e83bE
0000000000000000 W __extendsfdf2

I would have expected to see the f16 & f128 symbols there.

Running a rustc build in verbose mode, I see:

/Users/logic/Projects/rustc/llvm-head/build/bootstrap/debug/rustc /Users/logic/Projects/rustc/llvm-head/build/bootstrap/debug/rustc --crate-name compiler_builtins --edition=2021 /Users/logic/.cargo/registry/src/index.crates.io-6f17d22bba15001f/compiler_builtins-0.1.114/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=145 --crate-type lib --emit=dep-info,metadata,link --cfg 'feature="compiler-builtins"' --cfg 'feature="core"' --cfg 'feature="default"' --cfg 'feature="no-f16-f128"' --cfg 'feature="rustc-dep-of-std"' --target aarch64-apple-darwin <truncated>

Note the --cfg 'feature="no-f16-f128"' in there. This is on aarch64 which means that, AFAICT, no-f16-f128 should not trigger.

Commenting out

[target.'cfg(not(any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")))'.dependencies]
compiler_builtins = { version = "0.1.114", features = ["no-f16-f128"] }

Does produce a libcompiler_builtins.rlib which has the f16/f128 symbols.

[tgross35]

Per @ehuss, this is related to the old resolver https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Enabling.20features.20on.20specific.20targets/near/454918607

[TimNN]

I ran:

<env omitted> "/Users/logic/Projects/rustc/llvm-head/build/aarch64-apple-darwin/stage0/bin/cargo" "tree" -e features "--target" "aarch64-apple-darwin" "-Zbinary-dep-depinfo" "-v" "-v" "-v" "--features" " panic-unwind backtrace" "--manifest-path" "/Users/logic/Projects/rustc/llvm-head/library/sysroot/Cargo.toml" "-p" "alloc"
alloc v0.0.0 (/Users/logic/Projects/rustc/llvm-head/library/alloc)
├── compiler_builtins feature "default"
│   ├── compiler_builtins v0.1.114
│   │   └── rustc-std-workspace-core feature "default"
│   │       └── rustc-std-workspace-core v1.99.0 (/Users/logic/Projects/rustc/llvm-head/library/rustc-std-workspace-core)
│   │           └── core feature "default"
│   │               └── core v0.0.0 (/Users/logic/Projects/rustc/llvm-head/library/core)
│   └── compiler_builtins feature "compiler-builtins"
│       └── compiler_builtins v0.1.114 (*)
├── compiler_builtins feature "rustc-dep-of-std"
│   ├── compiler_builtins v0.1.114 (*)
│   ├── compiler_builtins feature "compiler-builtins" (*)
│   └── compiler_builtins feature "core"
│       └── compiler_builtins v0.1.114 (*)
└── core feature "default" (*)
[dev-dependencies]
├── rand feature "alloc"
│   ├── rand v0.8.5
│   │   └── rand_core feature "default"
│   │       └── rand_core v0.6.4
│   └── rand_core feature "alloc"
│       └── rand_core v0.6.4
└── rand_xorshift feature "default"
    └── rand_xorshift v0.3.0
        └── rand_core feature "default" (*)

So that doesn't show the feature being activated.

I also tried to set resolver = 2, which I think correctly made the no-f16-f128 feature not trigger, but this fails to compile stage 0 compiler_builtins, because f16.is_nan() doesn't exist.

[tgross35]

I also tried to set resolve = 2, which I think correctly made the no-f16-f128 feature not trigger, but this fails to compile stage 0 compiler_builtins, because f16.is_nan() doesn't exist.

Oh you're kidding, that's a third PR for me blocked on #128083 then :(. Guess if #128359 CI fails (likely based on your comment) I will just set no-f16-f128 on all platforms until the beta bump happens.

[TimNN]

If I override the rustc that compiles stage 0 and set resolver = 2, then for x build --stage 1 library/std I get a libcompiler_builtins.rlib that contains the f16/f128 symbols.

[tgross35]

Thanks for confirming, guess we are waiting on #128359 and then #128083.

[VorpalBlade]

Possibly related (so this is a regression that breaks code that compiles on stable): #128401

[TimNN]

Could we, as a quick fix on Resolver 1, move the

[target.'cfg(not(any(target_arch = "aarch64", target_arch = "x86", target_arch = "x86_64")))'.dependencies]
compiler_builtins = { version = "0.1.114", features = ["no-f16-f128"] }

bit into bootstrap?

[tgross35]

I was honestly thinking that maybe we should move that logic into compiler_builtins itself - always build unless the platform is known to have a LLVM crash or if no-f16-f128 is enabled. Then nothing in rust-lang/rust should have to worry about the feature flag unless it needs to be disabled.

I'll take a look at doing this in the morning.

[tgross35]

Wound up doing the above, compiler_builtins now checks here https://github.com/rust-lang/compiler-builtins/blob/cc385f4802dd69175b040dcc3b907477f74bb47c/configure.rs#L52-L92 to disable the extra float types on platforms where LLVM crashes. Then we configure what to actually test in std, based on platforms that are known to be bug-free

rust/library/std/build.rs

Lines 81 to 186 in 0399709

	// Emit these on platforms that have no known ABI bugs, LLVM selection bugs, lowering bugs,
	// missing symbols, or other problems, to determine when tests get run.
	// If more broken platforms are found, please update the tracking issue at
	// <https://github.com/rust-lang/rust/issues/116909>
	//
	// Some of these match arms are redundant; the goal is to separate reasons that the type is
	// unreliable, even when multiple reasons might fail the same platform.
	println!("cargo:rustc-check-cfg=cfg(reliable_f16)");
	println!("cargo:rustc-check-cfg=cfg(reliable_f128)");
	// This is a step beyond only having the types and basic functions available. Math functions
	// aren't consistently available or correct.
	println!("cargo:rustc-check-cfg=cfg(reliable_f16_math)");
	println!("cargo:rustc-check-cfg=cfg(reliable_f128_math)");
	let has_reliable_f16 = match (target_arch.as_str(), target_os.as_str()) {
	// We can always enable these in Miri as that is not affected by codegen bugs.
	_ if is_miri => true,
	// Selection failure until recent LLVM <https://github.com/llvm/llvm-project/issues/93894>
	// FIXME(llvm19): can probably be removed at the version bump
	("loongarch64", _) => false,
	// Selection failure <https://github.com/llvm/llvm-project/issues/50374>
	("s390x", _) => false,
	// Unsupported <https://github.com/llvm/llvm-project/issues/94434>
	("arm64ec", _) => false,
	// MinGW ABI bugs <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054>
	("x86_64", "windows") => false,
	// Apple has a special ABI for `f16` that we do not yet support
	// FIXME(builtins): fixed by <https://github.com/rust-lang/compiler-builtins/pull/675>
	("x86" | "x86_64", _) if target_vendor == "apple" => false,
	// Missing `__gnu_h2f_ieee` and `__gnu_f2h_ieee`
	("powerpc" | "powerpc64", _) => false,
	// Missing `__gnu_h2f_ieee` and `__gnu_f2h_ieee`
	("mips" | "mips32r6" | "mips64" | "mips64r6", _) => false,
	// Missing `__extendhfsf` and `__truncsfhf`
	("riscv32" | "riscv64", _) => false,
	// Most OSs are missing `__extendhfsf` and `__truncsfhf`
	(_, "linux" | "macos") => true,
	// Almost all OSs besides Linux and MacOS are missing symbols until compiler-builtins can
	// be updated. <https://github.com/rust-lang/rust/pull/125016> will get some of these, the
	// next CB update should get the rest.
	_ => false,
	};
	let has_reliable_f128 = match (target_arch.as_str(), target_os.as_str()) {
	// We can always enable these in Miri as that is not affected by codegen bugs.
	_ if is_miri => true,
	// Unsupported <https://github.com/llvm/llvm-project/issues/94434>
	("arm64ec", _) => false,
	// ABI and precision bugs <https://github.com/rust-lang/rust/issues/125109>
	// <https://github.com/rust-lang/rust/issues/125102>
	("powerpc" | "powerpc64", _) => false,
	// Selection bug <https://github.com/llvm/llvm-project/issues/95471>
	("nvptx64", _) => false,
	// ABI unsupported <https://github.com/llvm/llvm-project/issues/41838>
	("sparc", _) => false,
	// MinGW ABI bugs <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054>
	("x86_64", "windows") => false,
	// 64-bit Linux is about the only platform to have f128 symbols by default
	(_, "linux") if target_pointer_width == 64 => true,
	// Same as for f16, except MacOS is also missing f128 symbols.
	_ => false,
	};
	// Configure platforms that have reliable basics but may have unreliable math.
	// LLVM is currently adding missing routines, <https://github.com/llvm/llvm-project/issues/93566>
	let has_reliable_f16_math = has_reliable_f16
	&& match (target_arch.as_str(), target_os.as_str()) {
	// FIXME: Disabled on Miri as the intrinsics are not implemented yet.
	_ if is_miri => false,
	// x86 has a crash for `powi`: <https://github.com/llvm/llvm-project/issues/105747>
	("x86" | "x86_64", _) => false,
	// Assume that working `f16` means working `f16` math for most platforms, since
	// operations just go through `f32`.
	_ => true,
	};
	let has_reliable_f128_math = has_reliable_f128
	&& match (target_arch.as_str(), target_os.as_str()) {
	// FIXME: Disabled on Miri as the intrinsics are not implemented yet.
	_ if is_miri => false,
	// LLVM lowers `fp128` math to `long double` symbols even on platforms where
	// `long double` is not IEEE binary128. See
	// <https://github.com/llvm/llvm-project/issues/44744>.
	//
	// This rules out anything that doesn't have `long double` = `binary128`; <= 32 bits
	// (ld is `f64`), anything other than Linux (Windows and MacOS use `f64`), and `x86`
	// (ld is 80-bit extended precision).
	("x86_64", _) => false,
	(_, "linux") if target_pointer_width == 64 => true,
	_ => false,
	};
	if has_reliable_f16 {
	println!("cargo:rustc-cfg=reliable_f16");
	}
	if has_reliable_f128 {
	println!("cargo:rustc-cfg=reliable_f128");
	}
	if has_reliable_f16_math {
	println!("cargo:rustc-cfg=reliable_f16_math");
	}
	if has_reliable_f128_math {
	println!("cargo:rustc-cfg=reliable_f128_math");
	}

.

I think this should be resolved so I will close it. @TimNN mind double checking if you get the chance?

Reminder to self: this was about errors for missing symbols even when f16/f128 were not used, not only missing symbols when building and using float math.