LLVM error when array returned by function is stored in wrong-typed var

pub fn main() void {
    var arr: [4]f32 = undefined; // happens with any array type other than [16]f32
    arr = concat();
}
fn concat() [16]f32 {
    return [1]f32{0}**16;
}

Output:

Code Generation [129/453] std.debug.getLineNumberInfoDwarf...broken LLVM module found: Call parameter type does not match function signature!
  %arr = alloca [4 x float], align 4
 [16 x float]*  call fastcc void @concat([4 x float]* sret %arr), !dbg !14628

Above should be a compile error.

---

But this should probably work (assigning to compatible slice type):

pub fn main() void {
    var arr: []const f32 = undefined;
    arr = concat();
}   
fn concat() [16]f32 {
    return [1]f32{0}**16;
}   

But this one just outputs:

Code Generation [129/453] std.debug.getLineNumberInfoDwarf...Segmentation fault at address 0x0

---

Actually, that was a bit hackneyed. Here is a more realistic use case (which should work but also segfaults).

const Params = struct {
    slice: []const f32,
};
pub fn main() void {
    eatSlice(Params {
        .slice = concat(),
    });
}
fn eatSlice(params: Params) void {
}
fn concat() [16]f32 {
    return [1]f32{0}**16;
}

[Vexu]

This is caused by the compiler not adding an implicit cast for the function's return type Same thing happens with #3422, #3646, #3224 and #3327.

[Vexu]

In the last 2 examples first pass ir instructions make it into codegen which causes an assertion failure in ir_llvm_value.
They aren't related to the first example but I don't think there is a duplicate for them.

[Vexu]

Fixed by 5ea79bf

./build/a.zig:24:17: error: expected type '[4]f32', found '[16]f32'
    arr = concat();
                ^

The two other cases work if you take the address of the array.