android CI fails due to test_od::test_f16

[cre4ture]

[2024-02-04 15:54:39] --- TRY 3 STDERR:        coreutils::tests test_od::test_f16 ---
[2024-02-04 15:54:39] thread 'test_od::test_f16' panicked at tests/by-util/test_od.rs:255:10:
[2024-02-04 15:54:39] Command was expected to succeed.
[2024-02-04 15:54:39] stdout = 
[2024-02-04 15:54:39]  stderr = 
[2024-02-04 15:54:39] stack backtrace:
[2024-02-04 15:54:39] note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
[2024-02-04 15:54:39]

I put it as an issue as I'm currently not able to reproduce the issue on my simulator or real android device.
I'll try to work on it, but any input is welcome.

[cre4ture]

crate half-rs
half-rs/src/binary16/arch.rs:

#[inline]
pub(crate) fn f16_to_f64(i: u16) -> f64 {
    convert_fn! {
        if x86_feature("f16c") {
            unsafe { x86::f16_to_f32_x86_f16c(i) as f64 }
        } else if aarch64_feature("fp16") {
            unsafe { aarch64::f16_to_f64_fp16(i) }
        } else {
            f16_to_f64_fallback(i)
        }
    }
}

I think its failing in there.
I think it tries to use the "f16c" extension (which is available on the emulator).
But it fails and crashes.
There is no error message or panic.
I think it wasn't there on the MacOs runner.
It seems to be something very low-level

[tertsdiepraam]

That's unfortunate. Is there some small reproducible case we can create to submit as an issue to half?

[cre4ture]

Sadly no. I'm still not able to reproduce this issue locally. I was investigating the topic by adding logs and let it run on the CI.

[cre4ture]

Based on your proposal, I did a small test that reproduces the issue (in the CI):

#[test]
fn test_f16c_direct() {
    let bo = ::od::byteorder_io::ByteOrder::Little;
    let bits = bo.read_u16(&[0x00, 0x3c]);

    let result_f16 = half::f16::from_bits(bits);
    let result = f64::from(result_f16);
    assert_eq!(1.0, result);
}

[2024-02-10 17:43:12]  TRY 3 SIG 4 [   0.077s] coreutils::tests test_od::test_f16c_direct
[2024-02-10 17:43:12] 
[2024-02-10 17:43:12] --- TRY 3 STDOUT:        coreutils::tests test_od::test_f16c_direct ---
[2024-02-10 17:43:12] 
[2024-02-10 17:43:12] running 1 test
[2024-02-10 17:43:12] 
[2024-02-10 17:43:12] error: test run failed
Error: The process '/usr/bin/sh' failed with exit code 100

From that one can derive more information. It states SIG 4, which means "illegal instruction". So I guess that the emulator doesn't actually support the used instruction. Even though the /proc/cpuinfo states it.

[cre4ture]

Does anyone of you have a AMD CPU?

The ubuntu runners have an AMD CPU.
The MacOS runners have Intel.
I have Intel. Maybe thats why it is not reproducable on MacOs runners and on my machine.

[cre4ture]

As this issue seems really hard to fix, I see two short term actions to avoid a red CI:

1. Switch back to MacOS runners, which are significantly slower but do not have the f16c issue.
2. Disable this test for Android CI. Apparently the f16c usecase is something rarely used because all other tests are green.

@tertsdiepraam and @cakebaker what do you think?

[tertsdiepraam]

I like option 2, personally, but we should keep this issue open then. I'll also ping @sylvestre in addition to @cakebaker

[sylvestre]

yeah, please disable the test :)