Build failure on s390x

[est31]

I've tried to update the stdsimd module in rust, but got this build failure:

�[0KBuilding stage1 std artifacts (x86_64-unknown-linux-gnu -> s390x-unknown-linux-gnu)
[00:24:40] �[0m�[0m�[1m�[32m   Compiling�[0m cc v1.0.15
[00:24:40] �[0m�[0m�[1m�[32m   Compiling�[0m core v0.0.0 (file:///checkout/src/libcore)
[00:24:40] �[0m�[0m�[1m�[32m   Compiling�[0m unwind v0.0.0 (file:///checkout/src/libunwind)
[00:24:40] �[0m�[0m�[1m�[32m   Compiling�[0m build_helper v0.1.0 (file:///checkout/src/build_helper)
[00:24:46] �[0m�[0m�[1m�[32m   Compiling�[0m compiler_builtins v0.0.0 (file:///checkout/src/rustc/compiler_builtins_shim)
[00:24:46] �[0m�[0m�[1m�[32m   Compiling�[0m alloc_jemalloc v0.0.0 (file:///checkout/src/liballoc_jemalloc)
[00:24:46] �[0m�[0m�[1m�[32m   Compiling�[0m std v0.0.0 (file:///checkout/src/libstd)
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m ../../libcompiler_builtins/compiler-rt/lib/builtins/divdc3.c:21:1: warning: conflicting types for built-in function '__divdc3'
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m  __divdc3(double __a, double __b, double __c, double __d)
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m  ^
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m ../../libcompiler_builtins/compiler-rt/lib/builtins/divsc3.c:21:1: warning: conflicting types for built-in function '__divsc3'
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m  __divsc3(float __a, float __b, float __c, float __d)
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m  ^
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m ../../libcompiler_builtins/compiler-rt/lib/builtins/muldc3.c:21:1: warning: conflicting types for built-in function '__muldc3'
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m  __muldc3(double __a, double __b, double __c, double __d)
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m  ^
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m ../../libcompiler_builtins/compiler-rt/lib/builtins/mulsc3.c:21:1: warning: conflicting types for built-in function '__mulsc3'
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m  __mulsc3(float __a, float __b, float __c, float __d)
[00:24:55] �[0m�[0m�[1m�[33mwarning:�[0m  ^
[00:25:19] Intrinsic has incorrect return type!
[00:25:19] void (<16 x float>*, <16 x float>*)* @llvm.fabs.v16f32
[00:25:19] LLVM ERROR: Broken function found, compilation aborted!
[00:25:19] [RUSTC-TIMING] core test:false 39.625
[00:25:19] �[0m�[0m�[1m�[31merror:�[0m Could not compile `core`.

According to @kennytm a likely cause was #467

[kennytm]

(Well it has to be #467 because the symbol llvm.fabs.v16f32 is introduced by it and nowhere else 😄)

[gnzlbg]

So this is weird. Is anything else failing there beyond s390x ?

[est31]

travis aborts early if there is a build failure. So the other jobs are all shown as interrupted: https://travis-ci.org/rust-lang/rust/builds/396479389

[gnzlbg]

This codegen test works on s390x: https://github.com/rust-lang/rust/blob/master/src/test/codegen/simd-intrinsic-float-abs.rs#L68

but probably doesn't lower anything down to s390x.

This test doesn't cover that particular case: https://github.com/rust-lang/rust/blob/master/src/test/run-pass/simd-intrinsic-float-math.rs#L25

MWE (EDIT: does not produce the same error, see below):

#![feature(link_llvm_intrinsics, repr_simd, simd_ffi)]

#[allow(improper_ctypes)]
extern "C" {
    #[link_name = "llvm.fabs.v4f32"]
    fn abs_v4f32(x: F32x4) -> F32x4;
}

#[repr(simd)]
pub struct F32x4(
    f32, f32, f32, f32,
);

pub unsafe fn foo(x: F32x4) -> F32x4 { abs_v4f32(x) }

fails to compile for s390x-unknown-linux-gnu with:

Intrinsic has incorrect return type!
void (<4 x float>*, <4 x float>*)* @llvm.fabs.v4f32
LLVM ERROR: Broken function found, compilation aborted!

That error is different than the one being reported :/

The following LLVM-IR is generated:

define void @ttt::foo(<4 x float>* noalias nocapture sret dereferenceable(16), <4 x float>* noalias nocapture readonly dereferenceable(16) %x) unnamed_addr #0 {
start:
%1 = load <4 x float>, <4 x float>* %x, align 16
%2 = tail call <4 x float> @llvm.fabs.v4f32(<4 x float> %1)
store <4 x float> %2, <4 x float>* %0, align 16
ret void
}

which on godbolt works for s390x just fine: https://godbolt.org/g/hG54Vv emits:

foo: # @foo
  le %f0, 0(%r3)
  le %f1, 4(%r3)
  le %f2, 8(%r3)
  le %f3, 12(%r3)
  lpdfr %f0, %f0
  lpdfr %f1, %f1
  lpdfr %f2, %f2
  lpdfr %f3, %f3
  ste %f3, 12(%r2)
  ste %f2, 8(%r2)
  ste %f1, 4(%r2)
  ste %f0, 0(%r2)
  br %r14

[gnzlbg]

Looking more closely at the upstream error:

Intrinsic has incorrect return type!
[00:25:19] void (<16 x float>*, <16 x float>*)* @llvm.fabs.v16f32

It appears that the vector types are being passed via memory when calling the llvm intrinsics directly via link_llvm_intrinsics but this is something that shouldn't happen? cc @eddyb

[gnzlbg]

https://github.com/rust-lang/rust/pull/47743/files#diff-7977ffa598a44c353febcd69a0415479R894 That doesn't use the in memory abi if the ABI is the platform intrinsics ABI, but maybe it shouldn't use it either if we are calling llvm intrinsics directly via link_llvm_intrinsics. cc @rkruppe

[hanna-kruppe]

Modifying the ABI depending on some attribute on the function in question might get ugly, I don't think any attributes currently influence ABI calculation. But @eddyb would know better.

[eddyb]

@nagisa should know what to do here, since I believe they dealt with this before.
I personally think link_llvm_intrinsics is a bad idea overall, and quite unsustainable, but YMMV.

[nagisa]

For i128 we implemented a separate extern that did exactly what we needed on the platform IIRC.

…

On Mon, Jun 25, 2018, 22:36 Eduard-Mihai Burtescu ***@***.***> wrote: @nagisa <https://github.com/nagisa> should know what to do here, since I believe they dealt with this before. I personally think link_llvm_intrinsics is a bad idea overall, and quite unsustainable, but YMMV. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#498 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0ixj3PfuzZ7fwbnwcuG0UnWEeDSVks5uATuugaJpZM4U2nJS> .

[eddyb]

(FWIW I found what I was remembering: extern "unadjusted", used in compiler-builtins)