Description
rustc 1.71.1 fails to build for big-endian aarch64, such as e.g. aarch64_be-unknown-netbsd.
The reason may be universal reliance on the neon feature for aarch64, while I think that is
not available in big-endian mode.
I expected to see this happen: The (cross)build ought to succeed.
Instead, this happened: The build errors out with
error[E0432]: unresolved imports `core::arch::aarch64::vqtbl1q_u8`, `core::arch::aarch64::vtbl1_u8`
--> library/core/src/../../portable-simd/crates/core_simd/src/swizzle_dyn.rs:20:46
|
20 | use core::arch::aarch64::{uint8x8_t, vqtbl1q_u8, vtbl1_u8};
| ^^^^^^^^^^ ^^^^^^^^ no `vtbl1_u8` in `core_arch::arch::aarch64`
| |
| no `vqtbl1q_u8` in `core_arch::arch::aarch64`
|
help: a similar name exists in the module
|
20 | use core::arch::aarch64::{uint8x8_t, vst1q_u8, vtbl1_u8};
| ~~~~~~~~
help: a similar name exists in the module
|
20 | use core::arch::aarch64::{uint8x8_t, vqtbl1q_u8, vtrn1_u8};
| ~~~~~~~~
For more information about this error, try `rustc --explain E0432`.
Did not run successfully: exit status: 1
Meta
The implementation in
library/stdarch/crates/core_arch/src/aarch64/neon/mod.rs appears to only define
these if the target endian-ness is little-endian, ref.
/// Table look-up
#[inline]
#[cfg(target_endian = "little")]
#[target_feature(enable = "neon")]
#[cfg_attr(test, assert_instr(tbl))]
#[stable(feature = "neon_intrinsics", since = "1.59.0")]
pub unsafe fn vqtbl1q_u8(t: uint8x16_t, idx: uint8x16_t) -> uint8x16_t {
transmute(vqtbl1q(transmute(t), transmute(idx)))
}
This is seen when cross-building from NetBSD/amd64, using the following rustc version:
rustc --version --verbose:
: {21} work/rust-bootstrap/bin/rustc --version --verbose
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-netbsd
release: 1.70.0
LLVM version: 16.0.2
: {22}
The last successful cross-build for this target was with 1.70.0, so this is
a new problem which arrived together with 1.71.0.
I suspect this problem occurs for all big-endian aarch64 targets, the other ones being
aarch64_be-unknown-linux-gnu and aarch64_be-unknown-linux-gnu_ilp32.