`evaluation of constant value failed` on macOS M1

[mominul]

While compiling briansmith/ring@7c0024a on macOS M1 using

CARGO_PROFILE_DEV_CODEGEN_BACKEND=cranelift cargo +nightly build -Zcodegen-backend

the compiler errors out by issuing evaluation of constant value failed:

    Updating crates.io index
     Locking 73 packages to latest compatible versions
      Adding anes v0.1.6 (latest: v0.2.0)
      Adding hermit-abi v0.3.9 (latest: v0.4.0)
      Adding itertools v0.10.5 (latest: v0.13.0)
      Adding wasi v0.11.0+wasi-snapshot-preview1 (latest: v0.13.1+wasi-0.2.0)
  Downloaded cc v1.1.6
  Downloaded 1 crate (81.6 KB) in 0.36s
   Compiling libc v0.2.155
   Compiling cc v1.1.6
   Compiling cfg-if v1.0.0
   Compiling untrusted v0.9.0
   Compiling spin v0.9.8
   Compiling ring v0.17.8 (/Users/mominul/src/ring)
   Compiling getrandom v0.2.15
error[E0080]: evaluation of constant value failed
  --> src/cpu/arm/darwin.rs:44:5
   |
44 |     assert!((ARMCAP_STATIC & MIN_STATIC_FEATURES) == MIN_STATIC_FEATURES);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: (ARMCAP_STATIC & MIN_STATIC_FEATURES) == MIN_STATIC_FEATURES', src/cpu/arm/darwin.rs:44:5
   |
   = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0080]: evaluation of constant value failed
  --> src/cpu/arm/darwin.rs:51:5
   |
51 |     assert!(ARMCAP_STATIC == MIN_STATIC_FEATURES);
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'assertion failed: ARMCAP_STATIC == MIN_STATIC_FEATURES', src/cpu/arm/darwin.rs:51:5
   |
   = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: unnecessary `unsafe` block
   --> src/cpu/arm.rs:184:21
    |
184 |             let p = unsafe { ptr::addr_of_mut!(OPENSSL_armcap_P) };
    |                     ^^^^^^ unnecessary `unsafe` block
    |
    = note: `#[warn(unused_unsafe)]` on by default

warning: unnecessary `unsafe` block
   --> src/cpu/arm.rs:202:17
    |
202 |         let p = unsafe { ptr::addr_of!(OPENSSL_armcap_P) };
    |                 ^^^^^^ unnecessary `unsafe` block

For more information about this error, try `rustc --explain E0080`.
warning: `ring` (lib) generated 2 warnings
error: could not compile `ring` (lib) due to 2 previous errors; 2 warnings emitted

Nightly rust version:

rustc 1.82.0-nightly (7120fdac7 2024-07-25)

Thanks for the enormous work! ❤️

[bjorn3]

Looks like ring assumes that on arm64 macOS, the neon, aes, sha256 and pmull features are available: https://github.com/briansmith/ring/blob/7c0024abaf4fd59250c9b79cc41a029aa0ef3497/src/cpu/arm/darwin.rs#L35 This is indeed the case, but except for neon, cg_clif doesn't set them in target_features, so they are not listed as statically available for cfg(target_feature = "..."), only detected at runtime using is_aarch64_feature_detected!(). The fix would be to add a case for aarch64-apple-darwin to

rustc_codegen_cranelift/src/lib.rs

Lines 194 to 196 in 39bc103

	} else if sess.target.arch == "aarch64" && sess.target.os != "none" {
	// AArch64 mandates Neon support
	vec![sym::neon]

that enables these features. In addition I think the pmull intrinsics are not yet implemented.

[mominul]

@bjorn3 Can you drop some pointers on how this should be properly implemented? Or how LLVM handles it? I am interested to working on it.

[bjorn3]

For cfg(target_feature) that would be adding another case like

rustc_codegen_cranelift/src/lib.rs

Line 194 in 68b99fc

} else if sess.target.arch == "aarch64" && sess.target.os != "none" {

for arm64 apple which enables not just neon, but also aes, sha256 and pmull as target features. As for the presumably missing intrinsics, that would be in src/intrinsics/aarch64.rs and implemented on a case-by-case basis. I've got a wip branch to automatically generate all intrinsic implementations based on the LLVM implementations, but it doesn't actually work yet.

[mominul]

@bjorn3 I am thinking of using the cpufeatures crate to pass the detected features to target_features, that would also fix the FIXME I think.

Should I follow this approach?

[bjorn3]

That doesn't work for cross-compilation. And it only supports part of the target features ring needs anyway. The features ring need are default features for the arm64-apple-darwin target, so adding a case like

rustc_codegen_cranelift/src/lib.rs

Line 194 in 68b99fc

} else if sess.target.arch == "aarch64" && sess.target.os != "none" {

with those defaults is the right option until Cranelift itself knows about those default features and allows querying them.

[bjorn3]

Ring's test suite passes on arm64 macOS now.