#[target_feature(enable = "simd128")] does not work properly on 1.73, but work fine on 1.72.1

[mrDIMAS]

Code

I tried this code on 1.73:

use std::arch::wasm32::*;

#[target_feature(enable = "simd128")]
fn foo() {
	const FOO: v128 = i8x16(0, 1, -1, -1, -1, -1, -1, -1, 2, 3, -1, -1, -1, -1, -1, -1);
	println!("{:?}", FOO);
}

fn main() {
    foo();
}

Compiled it with cargo build --target=wasm32-unknown-unknown, I expected it to compile fine as on previous 1.72.1, but it gave me these errors:

$ cargo build --target=wasm32-unknown-unknown
   Compiling regression_test v0.1.0 (C:\Users\123\Desktop\regression_test)
error[E0080]: evaluation of constant value failed
 --> src\main.rs:5:20
  |
5 |     const FOO: v128 = i8x16(0, 1, -1, -1, -1, -1, -1, -1, 2, 3, -1, -1, -1, -1, -1, -1);
  |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ calling a function that requires unavailable target features: simd128

note: erroneous constant used
 --> src\main.rs:6:19
  |
6 |     println!("{:?}", FOO);
  |                      ^^^

note: erroneous constant used
 --> src\main.rs:6:19
  |
6 |     println!("{:?}", FOO);
  |                      ^^^
  |
  = note: this note originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0080`.
error: could not compile `regression_test` (bin "regression_test") due to previous error

Version it worked on

It most recently worked on: 1.72.1

Output:

$ cargo build --target=wasm32-unknown-unknown
Compiling regression_test v0.1.0 (C:\Users\123\Desktop\regression_test)
    Finished dev [unoptimized + debuginfo] target(s) in 0.13s

Version with regression

rustc --version --verbose:

$ rustc --version --verbose
rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: x86_64-pc-windows-msvc
release: 1.73.0
LLVM version: 17.0.2

Other

I read release notes for 1.73 and couldn't find anything that could be related to this, also tried to search for an existing issue about this - no luck. This issue also broke compilation of fast_image_resize crate and transitively, Fyrox game engine.

[ehuss]

Bisected to #113720. cc @RalfJung

[saethlin]

And then this was fixed by (or at least it started compiling since) #115580

[RalfJung]

Hm, why does it think that the i8x16 function requires that target feature? That function doesn't have any target_feature attribute...

Cc @eduardosm

[RalfJung]

Ah, that's what changed in #115580 -- that attribute got removed from a bunch of functions.

This was changed in rust-lang/stdarch#1448. Cc @Amanieu

[Amanieu]

That was changed in stdarch specifically in response to #113720, to avoid breaking users who were using the const fn already.

[RalfJung]

In principle we could probably silence this check on wasm, since we document wasm to be a target where calling functions with unsupported target features is safe.

[eduardosm]

What happens in wasm when you call a function that requires an unavailable target feature?

[RalfJung]

I am told that the wasm runtime will refuse to even load a module that contains invalid operations, so there are two options:

• the generated code makes no use of the target feature, and so everything just works
• the generated code makes use of the target feature, and we don't even ever get to the function call since loading the wasm module already failed

[apiraino]

@mrDIMAS can you check on of the latest nightlies to verify if it works for you? (ref. comment)

[RalfJung]

We have a special exception for wasm that allows target_feature functions to not be marked unsafe:

rust/compiler/rustc_codegen_ssa/src/codegen_attrs.rs

Lines 279 to 309 in 8fa7bdf

	if tcx.sess.target.is_like_wasm || tcx.sess.opts.actually_rustdoc {
	// The `#[target_feature]` attribute is allowed on
	// WebAssembly targets on all functions, including safe
	// ones. Other targets require that `#[target_feature]` is
	// only applied to unsafe functions (pending the
	// `target_feature_11` feature) because on most targets
	// execution of instructions that are not supported is
	// considered undefined behavior. For WebAssembly which is a
	// 100% safe target at execution time it's not possible to
	// execute undefined instructions, and even if a future
	// feature was added in some form for this it would be a
	// deterministic trap. There is no undefined behavior when
	// executing WebAssembly so `#[target_feature]` is allowed
	// on safe functions (but again, only for WebAssembly)
	//
	// Note that this is also allowed if `actually_rustdoc` so
	// if a target is documenting some wasm-specific code then
	// it's not spuriously denied.
	//
	// This exception needs to be kept in sync with allowing
	// `#[target_feature]` on `main` and `start`.
	} else if !tcx.features().target_feature_11 {
	let mut err = feature_err(
	&tcx.sess.parse_sess,
	sym::target_feature_11,
	attr.span,
	"`#[target_feature(..)]` can only be applied to `unsafe` functions",
	);
	err.span_label(tcx.def_span(did), "not an `unsafe` function");
	err.emit();
	} else {

We should probably have the same exception in the target-feature check in the interpreter. @eduardosm do you have the time for a follow-up PR implementing that?

[mrDIMAS]

@apiraino I re-checked on latest nightly and seems to work fine:

$ rustup default nightly
info: using existing install for 'nightly-x86_64-pc-windows-msvc'
info: default toolchain set to 'nightly-x86_64-pc-windows-msvc'

  nightly-x86_64-pc-windows-msvc unchanged - rustc 1.75.0-nightly (bf9a1c8a1 2023-10-08)

$ rustup target add wasm32-unknown-unknown
info: downloading component 'rust-std' for 'wasm32-unknown-unknown'
info: installing component 'rust-std' for 'wasm32-unknown-unknown'

$ cargo build --target=wasm32-unknown-unknown
   Compiling fail v0.1.0 (C:\Users\123\Desktop\regression_test)
    Finished dev [unoptimized + debuginfo] target(s) in 0.18s

[eduardosm]

do you have the time for a follow-up PR implementing that?

I will do that

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

Issue is fixed on nightly+beta, leaving open to follow PR #116576 fixing this comment

@rustbot label -I-prioritize +P-medium

[mrDIMAS]

In which version this fix will be included?

[apiraino]

In which version this fix will be included?

Should land in stable 1.74 (around mid November), iiuc.

See release cycle or an easier to read calendar