Wrapping simd call results in compiler panic (nightly)

[dignifiedquire]

Expected the following code to compile

#[cfg(target_arch = "x86")]
use core::arch::x86::*;
#[cfg(target_arch = "x86_64")]
use core::arch::x86_64::*;

unsafe fn pclmul(a: __m128i, b: __m128i, imm8: i32) -> __m128i {
    _mm_clmulepi64_si128(a, b, imm8)
}

But getting

Standard Error

   Compiling playground v0.0.1 (/playground)
thread 'rustc' panicked at 'index out of bounds: the len is 2 but the index is 3', /rustc/fbd34efb32b9efb574899e4335bdc8c6525ac27e/src/libcore/slice/mod.rs:2539:10
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.35.0-nightly (fbd34efb3 2019-03-26) running on x86_64-unknown-linux-gnu

note: compiler flags: -C codegen-units=1 -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

Repro:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=36e55f5180a9cf903585dead5b4c2a8d

[jonas-schievink]

Also happens on beta, not on stable

[jonas-schievink]

Stable says:

error: argument 3 is required to be a constant
 --> src/lib.rs:7:5
  |
7 |     _mm_clmulepi64_si128(a, b, imm8)
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

[dignifiedquire]

For reference, the function signature as defined here is exactly the same.

[hellow554]

The actual ICE occurs first in nightly-2019-03-03 (c1d2d83...0ea2271).

But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (f47ec2a...a9410cd) this does not emit an error anymore, but also does not ICE.

[hellow554]

I guess for the "does not emit an error anymore" @eddyb can say something about it. #58403 should be responsible for it.

[pnkfelix]

triage: P-high

[eddyb]

@dignifiedquire Note that because of the #[rustc_args_required_const(2)] on the definition, you can't wrap it (without matching on imm8 and having 256 separate calls).

@hellow554 I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc @oli-obk @gnzlbg

[gnzlbg]

So I agree that this code can't compile, that's the expected behavior; @dignifiedquire if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet.

The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.

[pnkfelix]

triage, assigning to self to fix the stable-to-beta regression.

[pnkfelix]

The behavior here varies with edition as well as channel.

edition	2015	2018
stable	expected error	expected error
beta	unexpected compile-pass	unexpected compile-pass
nightly-2019-04-05	unexpected compile-pass	ICE

I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.

[pnkfelix]

The easiest thing might be to revert #58403

[oli-obk]

I have an actual fix in #59724 (also easier to backport than a revert)

[pnkfelix]

Okay then I'm reassigning to @oli-obk