search

ziglang / zig

General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
https://ziglang.org
MIT License
34.79k stars 2.54k forks source link

stage1: Build failure on SPARCv9 #10872

Closed koachan closed 2 years ago

koachan commented 2 years ago

Zig Version

0.10.0-dev.689+9643f32c9

Steps to Reproduce

Build Zig using the usual steps on a Linux/sparc64 environment:

git clone https://github.com/ziglang/zig
mkdir zig/out
cd zig/out
cmake .. && make

Expected Behavior

It builds without error.

Actual Behavior

Got this error when building zig1.o:

broken LLVM module found: Call parameter type does not match function signature!
  %34 = load half, half* %33, align 2, !dbg !327373
 i16  %35 = call i80 @__extendhfxf2(half %34), !dbg !327374
Stored value type does not match pointer operand type!
  store i16 %54, half* %result, align 2, !dbg !375643
 i16
This is a bug in the Zig compiler.
koachan commented 2 years ago

From what I understand so far, at least part of the bug is in C++ side of the code (maybe gen_soft_f80_widen_or_shorten?) which seems to generate mismatched type in signature/call.

I still don't know what generates the store mismatch, will need to look into it later.

koachan commented 2 years ago

I found out that in codegen.cpp:1561 at gen_soft_f80_widen_or_shorten, it sets the param type to LLVM half, but on SPARCv9, at least, __extendhfxf2 expects an LLVM i16 parameter.

This is the reason why it throws the Call parameter type does not match function signature! error.

matu3ba commented 2 years ago

Do you have any idea, why the sourcehut runner fails with752/1098 behavior.floatop.test "behavior-native-Debug--multi @sqrt"... behavior.floatop.test "behavior-native-Debug--multi @sqrt"... FAIL ? It looks like it fails on floating stuff, which your change relates (distantly) to.

koachan commented 2 years ago

Do you have any idea, why the sourcehut runner fails with752/1098 behavior.floatop.test "behavior-native-Debug--multi @sqrt"... behavior.floatop.test "behavior-native-Debug--multi @sqrt"... FAIL ? It looks like it fails on floating stuff, which your change relates (distantly) to.

Yep, I noticed it too, and I'm trying to debug it. Seems like it fails when trying to do @sqrt on an f80 type?

From what I can see, the bug seems to affect the FreeBSD build, and sadly I am unable to reproduce it on Linux (both on x86_64 and SPARCv9). I'll see what else I can do to help with it.