Enable f16 in assembly on aarch64 platforms that support it

[lengrongfu]

Issue: #125398

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @oli-obk (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[lengrongfu]

r? @tgross35

[rustbot]

Failed to set assignee to tgross35: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[tgross35]

That was fast :)

Can you change the “fixes” tag so it doesn’t close that issue? We’ll still have to add the other platforms, but those can come separately

@rustbot label +F-f16_and_f128

[oli-obk]

Don't we have the same issues for f128?

[tgross35]

It's probably okay to handle f128 in a separate PR, since we might want a special test that it actually works right on s390x (it has f128 arithmetic operations but it looks like the float ABI might not use vector registers?). Still no harm in having it here without enabling it on a target of course

[oli-obk]

@bors r+ rollup

[bors]

📌 Commit 488fac9 has been approved by oli-obk

It is now in the queue for this repository.

[matthiaskrgr]

@bors r- #126124 (comment)

[tgross35]

@lengrongfu for reference if you are on an x86 host, you are supposed to be able to replicate the CI tests by running ./src/ci/docker/run.sh dist-aarch64-linux (see https://rustc-dev-guide.rust-lang.org/tests/docker.html). However it doesn't seem to work for me, so I don't know if you'd have better luck.

So if that doesn't work and you don't have an aarch host, you can just temporarily enable the aarch64 CI test to verify this PR (without reapproval and bors running the full suite). https://rustc-dev-guide.rust-lang.org/tests/ci.html#using-ci-to-test

[lengrongfu]

@tgross35 I use macOS m3, which is aarch64 arch. I use ./x t --stage 1 tests/ui/asm/aarch64/type-f16.rs command to test, but it does not have any error info, but the test result is FAILED. can you help me?

file tests/ui/asm/aarch64/type-f16.rs content is:

//@ only-aarch64

#![feature(f16, f128)]
use std::arch::asm;
#[inline(never)]
pub fn f32_to_f16_asm(a: f32) -> f16 {
    let ret: f16;
    unsafe {
        asm!(
        "fcvt    {ret:h}, {a:s}",
        a = in(vreg) a,
        ret = lateout(vreg) ret,
        options(nomem, nostack),
        );
    }
    ret
}

fn main() {
    
}

[tgross35]

UI tests are expected to produce errors by default, meaning you need a .stderr file and ERROR directives. You need to add either //@ check-pass to indicate that a check should be successful, //@ build-pass if it should fully link, or //@ run-pass if you want it to actually run (only if you add assertions, like here).

You probably want either build-pass or assertions + run-pass here to make sure LLVM actually sees the assembly, I don’t think check-pass does that.

There is some more info here: https://rustc-dev-guide.rust-lang.org/tests/ui.html

[tgross35]

@lengrongfu comment @rustbot ready whenever you have it passing locally and are ready for another review

[lengrongfu]

@rustbot ready

[Amanieu]

This needs tests in tests/assembly/asm. See #126417 for an example.

[Amanieu]

@rustbot author

[tgross35]

@lengrongfu are you able to rebase this and add a test? You can drop the changes to hir_analysis and target/src/asm/mod.rs since they were added in #126417, meaning this PR will look more like #126555.

[rustbot]

Some changes occurred in src/tools/cargo

cc @ehuss

[tgross35]

Looks like you accidentally grabbed submodules while rebasing. You can do git submodule deinit --all -f to unsync them before rebasing if they show up in git status.

[rustbot]

There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged.

You can start a rebase with the following commands:

$ # rebase
$ git pull --rebase https://github.com/rust-lang/rust.git master
$ git push --force-with-lease

The following commits are merge commits:

• 6391e70

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    Checking addr2line v0.22.0
error[E0308]: `?` operator has incompatible types
   --> library/std/src/../../backtrace/src/symbolize/gimli/macho.rs:262:44
    |
262 |             *mapping = Some(object_mapping(object_map.objects().get(object_index)?));
    |                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `&[u8]`, found `&ObjectMapFile<'_>`
    |
    = note: `?` operator cannot convert from `&ObjectMapFile<'_>` to `&[u8]`
    = note: expected reference `&[u8]`
               found reference `&ObjectMapFile<'_>`
For more information about this error, try `rustc --explain E0308`.
error: could not compile `std` (lib) due to 1 previous error
Build completed unsuccessfully in 0:01:10
  local time: Thu Jun 27 13:49:18 UTC 2024