mirror of
https://github.com/rust-lang/rust.git
synced 2025-11-25 03:58:00 +00:00
e0e6243b21
Since there are more platforms that do not have symbols present, we need to use `rustc_apfloat` for more conversion tests. Make use of the fallback like other tests, and refactor so each test gets its own function. Previously we were testing both apfloat and system conversion methods when possible. This changes to only test one or the other, depending on whether or not the system version is available. This seems reasonable because it is consistent with all other tests, but we should consider updating all tests to check both at some point. This also includes an adjustment of PowerPC configuration to account for the linking errors at [1]. [1]: https://github.com/rust-lang/compiler-builtins/issues/655
81 lines
3.4 KiB
Rust
81 lines
3.4 KiB
Rust
use std::{collections::HashSet, env};
|
|
|
|
/// Features to enable
|
|
#[derive(Debug, PartialEq, Eq, Hash)]
|
|
enum Feature {
|
|
NoSysF128,
|
|
NoSysF128IntConvert,
|
|
NoSysF16,
|
|
NoSysF16F128Convert,
|
|
}
|
|
|
|
fn main() {
|
|
let target = env::var("TARGET").unwrap();
|
|
let mut features = HashSet::new();
|
|
|
|
// These platforms do not have f128 symbols available in their system libraries, so
|
|
// skip related tests.
|
|
if target.starts_with("arm-")
|
|
|| target.contains("apple-darwin")
|
|
|| target.contains("windows-msvc")
|
|
// GCC and LLVM disagree on the ABI of `f16` and `f128` with MinGW. See
|
|
// <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054>.
|
|
|| target.contains("windows-gnu")
|
|
// FIXME(llvm): There is an ABI incompatibility between GCC and Clang on 32-bit x86.
|
|
// See <https://github.com/llvm/llvm-project/issues/77401>.
|
|
|| target.starts_with("i686")
|
|
// 32-bit PowerPC and 64-bit LE gets code generated that Qemu cannot handle. See
|
|
// <https://github.com/rust-lang/compiler-builtins/pull/606#issuecomment-2105635926>.
|
|
|| target.starts_with("powerpc-")
|
|
|| target.starts_with("powerpc64le-")
|
|
// FIXME: We get different results from the builtin functions. See
|
|
// <https://github.com/rust-lang/compiler-builtins/pull/606#issuecomment-2105657287>.
|
|
|| target.starts_with("powerpc64-")
|
|
{
|
|
features.insert(Feature::NoSysF128);
|
|
features.insert(Feature::NoSysF128IntConvert);
|
|
features.insert(Feature::NoSysF16F128Convert);
|
|
}
|
|
|
|
if target.starts_with("i586") || target.starts_with("i686") {
|
|
// 32-bit x86 does not have `__fixunstfti`/`__fixtfti` but does have everything else
|
|
features.insert(Feature::NoSysF128IntConvert);
|
|
// FIXME: 32-bit x86 has a bug in `f128 -> f16` system libraries
|
|
features.insert(Feature::NoSysF16F128Convert);
|
|
}
|
|
|
|
// These platforms do not have f16 symbols available in their system libraries, so
|
|
// skip related tests. Most of these are missing `f16 <-> f32` conversion routines.
|
|
if (target.starts_with("aarch64-") && target.contains("linux"))
|
|
|| target.starts_with("arm")
|
|
|| target.starts_with("powerpc-")
|
|
|| target.starts_with("powerpc64-")
|
|
|| target.starts_with("powerpc64le-")
|
|
|| target.starts_with("i586-")
|
|
|| target.contains("windows-")
|
|
// Linking says "error: function signature mismatch: __extendhfsf2" and seems to
|
|
// think the signature is either `(i32) -> f32` or `(f32) -> f32`
|
|
|| target.starts_with("wasm32-")
|
|
{
|
|
features.insert(Feature::NoSysF16);
|
|
features.insert(Feature::NoSysF16F128Convert);
|
|
}
|
|
|
|
for feature in features {
|
|
let (name, warning) = match feature {
|
|
Feature::NoSysF128 => ("no-sys-f128", "using apfloat fallback for f128"),
|
|
Feature::NoSysF128IntConvert => (
|
|
"no-sys-f128-int-convert",
|
|
"using apfloat fallback for f128 to int conversions",
|
|
),
|
|
Feature::NoSysF16F128Convert => (
|
|
"no-sys-f16-f128-convert",
|
|
"skipping using apfloat fallback for f16 <-> f128 conversions",
|
|
),
|
|
Feature::NoSysF16 => ("no-sys-f16", "using apfloat fallback for f16"),
|
|
};
|
|
println!("cargo:warning={warning}");
|
|
println!("cargo:rustc-cfg=feature=\"{name}\"");
|
|
}
|
|
}
|