Compile test_num_f128 conditionally on reliable_f128_math config

[raoulstrackx]

With #132434 merged, our internal SGX CI started failing with:

05:27:34   = note: rust-lld: error: undefined symbol: fmodl
05:27:34           >>> referenced by arith.rs:617 (core/src/ops/arith.rs:617)
05:27:34           >>>               /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/std-5d5f11eb008c9091.std.d8141acc61ab7ac8-cgu.10.rcgu.o:(std::num::test_num::h7dd9449f6c01fde8)
05:27:34           >>> did you mean: fmodf
05:27:34           >>> defined in: /home/jenkins/workspace/rust-sgx-ci/rust/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-fortanix-unknown-sgx/release/deps/libcompiler_builtins-0376f439a2ebf305.rlib(compiler_builtins-0376f439a2ebf305.compiler_builtins.c22db39d25d6f802-cgu.148.rcgu.o)

This originated from the test_num_f128 test not having the required conditional compilation. This PR fixes that issue.

cc: @jethrogb, @workingjubilee

[rustbot]

r? @workingjubilee

rustbot has assigned @workingjubilee.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[raoulstrackx]

This doesn't seem to work. I disregarded that as I wanted to have a minimal PR. Should I remove this, move the conditional compilation to the mod tests; statement (but that's even easier for developers to miss), or use a mod statement within this tests module with a proper single conditional compilation statement?

[tgross35]

That config is set here

rust/library/std/build.rs

Lines 120 to 143 in 4d215e2

	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,
	// Selection bug <https://github.com/llvm/llvm-project/issues/96432>
	("mips64" | "mips64r6", _) => false,
	// Selection bug <https://github.com/llvm/llvm-project/issues/95471>
	("nvptx64", _) => false,
	// ABI bugs <https://github.com/rust-lang/rust/issues/125109> et al. (full
	// list at <https://github.com/rust-lang/rust/issues/116909>)
	("powerpc" | "powerpc64", _) => false,
	// ABI unsupported <https://github.com/llvm/llvm-project/issues/41838>
	("sparc", _) => false,
	// Stack alignment bug <https://github.com/llvm/llvm-project/issues/77401>. NB: tests may
	// not fail if our compiler-builtins is linked.
	("x86", _) => false,
	// MinGW ABI bugs <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054>
	("x86_64", "windows") if target_env == "gnu" && target_abi != "llvm" => false,
	// There are no known problems on other platforms, so the only requirement is that symbols
	// are available. `compiler-builtins` provides all symbols required for core `f128`
	// support, so this should work for everything else.
	_ => true,
	};

and at this point should really only cover platforms where LLVM crashes or ABI problems lead to buggy results. reliable_f128_math is the gate that should cover anything that relies on libm symbols. I think we just didn't catch this because fmodl is available on many platforms even when the rest of the math symbols might not be.

So moving only calls to functions that rely on f128 libm to reliable_f128_math should be the needed correction (suggested by @beetrees below), everything else should continue to work on SGX and other platforms as long as it isn't in the linked list.

[jethrogb]

LGTM

[beetrees]

cc @tgross35

[tgross35]

r? @tgross35

[tgross35]

Could you apply beetrees suggestion and ./x fmt to fix the tidy bug? Should be good after that (and a squash)

@rustbot author

[workingjubilee]

Sorry about that folks, we've been trying to make the builtins calls less of a problem but it's slow going.

[tgross35]

@bors r+

[bors]

📌 Commit 0720880 has been approved by tgross35

It is now in the queue for this repository.