evaluation of constant value failed on nightly
#74
Comments
|
RustFFT 6.0.1 has peen published, which fixes this issue. Thanks Herschel for reporting, and thanks to Henrik Enquist for fixing. |
|
I have also backported this to a version 5.1.1 |
|
Thank you for the very prompt fix! |
Herschel
added a commit
to Herschel/ruffle
that referenced
this issue
May 11, 2021
Bump rustfft to 5.1.1, which fixes this issue affecting our nightly build: ejmahler/RustFFT#74
Herschel
added a commit
to ruffle-rs/ruffle
that referenced
this issue
May 11, 2021
Bump rustfft to 5.1.1, which fixes this issue affecting our nightly build: ejmahler/RustFFT#74
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
May 26, 2021
Post-monomorphization errors traces MVP This PR works towards better diagnostics for the errors encountered in rust-lang#85155 and similar. We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate). These kinds of errors will be more likely now that `stdarch` uses const generics for its intrinsics' immediate arguments, and validates these const arguments with a mechanism that triggers such PMEs. (Not to mention that the errors happen during codegen, so only when building code that actually uses these code paths. Check builds don't trigger them, neither does unused code) So in this PR, we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors, we print a diagnostic about the current collection step, so that the user has at least some context of which erroneous code and dependency triggered the error. The diagnostics for issue rust-lang#85155 now have this note showing the source of the erroneous const argument: ``` note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>` --> issue-85155.rs:11:24 | 11 | let _blended = _mm_blend_ps(a, b, 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error ``` Note that rust-lang#85155 is a reduced version of a case happening in the wild, to indirect users of the `rustfft` crate, as seen in ejmahler/RustFFT#74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed: <details> ``` error[E0080]: evaluation of constant value failed --> ./stdarch/crates/core_arch/src/macros.rs:8:9 | 8 | assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9 | = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info) note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23 | 1314 | let blended = _mm_blend_ps(rows[0], rows[2], 0x33); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9 | 1859 | _mm_permute_pd(self, 0x05) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>` --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32 | 1863 | (_mm_movedup_pd(self), _mm_permute_pd(self, 0x0F)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. error: could not compile `rustfft` To learn more, run the command again with --verbose. ``` </details> I've developed and discussed this with them, so maybe r? `@oli-obk` -- but feel free to redirect to someone else of course. (I'm not sure we can say that this PR definitely closes issue 85155, as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli, but we decided to not include them in this PR for now)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
rustfft fails to build on rustc nightly for 05/09 and later:
It is hitting this faux static assert in std::arch:
https://github.com/rust-lang/stdarch/blob/master/crates/core_arch/src/macros.rs#L5-L10
probably becomes one of the SIMD calls is passing an out-of-range value. This unfortunately affects downstream crates that depend on rustfft.
The text was updated successfully, but these errors were encountered: