Crash targetting aarch64 without floating point and neon

[N00byEdge]

Zig Version

0.11.0-dev.1465+d64dd75e3

Steps to Reproduce and Observed Behavior

zig build-exe empty.zig -target aarch64-freestanding-none -mcpu=generic-fp_armv8-neon
[1]    2754 segmentation fault (core dumped)
zig build-exe empty.zig -target aarch64-linux -mcpu=generic-fp_armv8-neon
[1]    3374 segmentation fault (core dumped)

Working -mcpu values: generic-fp_armv8, generic-neon or just leaving the argument out entirely. I don't have a debug build of the compiler, sorry

Expected Behavior

That the compiler doesn't crash

[davidgmbb]

I tried to reproduce it in my pc with a release build of LLVM and although the stack trace doesn't say much, it looks like it's a debug info problem:

[0] from 0x00007fffee871ab5 in llvm::DwarfDebug::beginFunctionImpl(llvm::MachineFunction const*)
[1] from 0x990d8df25e0eb100
[2] from 0x0000000003c4f8d0
[3] from 0x00007ffffffe5980
[4] from 0x00007ffffffe5b80
[5] from 0x0000000003c4f8d0
[6] from 0x0000000002bcbfe0
[7] from 0x0000000003c51270
[8] from 0x0000000000000000

 0x00007fffee871ab5  ? mov    0x1c(%rsi),%eax
 0x00007fffee871ab8  ? test   %eax,%eax
 0x00007fffee871aba  ? je     0x7fffee871a7c <_ZN4llvm10DwarfDebug17beginFunctionImplEPKNS_15MachineFunctionE+76>
 0x00007fffee871abc  ? mov    %rbx,%rdi
 0x00007fffee871abf  ? call   0x7fffee870ba0 <_ZN4llvm10DwarfDebug27getOrCreateDwarfCompileUnitEPKNS_13DICompileUnitE>
 0x00007fffee871ac4  ? lea    -0x2b12b(%rip),%rcx        # 0x7fffee8469a0
 0x00007fffee871acb  ? mov    %rax,%r12
 0x00007fffee871ace  ? mov    0x8(%rbx),%rax
 0x00007fffee871ad2  ? mov    0x110(%rax),%rdi
 0x00007fffee871ad9  ? mov    (%rdi),%rax

[Vexu]

Possibly caused by #12227

[N00byEdge]

Possibly caused by #12227

Do you suspect disabling fp and neon is a conflict somehow? They seem very compatible to me.

[Vexu]

Not each other but maybe some other feature enabled by default?

[N00byEdge]

That could definitely be it, good thinking.

[msiedlarek]

Stumbled upon this myself, and I do have a debug build of the compiler. Compiling a minimal program

pub fn main() void {}

with

zig build-exe -target aarch64-linux -mcpu generic-fp_armv8-neon main.zig

causes Zig to crash hitting llvm_unreachable in llvm::MVT::getVectorMinNumElements()

LLVM Emit Object... Process 60105 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
    frame #0: 0x0000000104dbad41 zig`llvm::MVT::getVectorMinNumElements() const + 49
zig`llvm::MVT::getVectorMinNumElements:
->  0x104dbad41 <+49>: ud2
    0x104dbad43 <+51>: movl   $0x400, %eax              ; imm = 0x400
    0x104dbad48 <+56>: movl   %eax, -0x10(%rbp)
    0x104dbad4b <+59>: jmp    0x104dbae3a               ; <+298>
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x0000000104dbad41 zig`llvm::MVT::getVectorMinNumElements() const + 49
    frame #1: 0x0000000104dcf83e zig`llvm::EVT::getVectorElementCount() const + 30
    frame #2: 0x000000010588be31 zig`llvm::SelectionDAG::SplitVector(llvm::SDValue const&, llvm::SDLoc const&, llvm::EVT const&, llvm::EVT const&) + 417
    frame #3: 0x0000000106239873 zig`llvm::SelectionDAG::SplitVectorOperand(llvm::SDNode const*, unsigned int) + 211
    frame #4: 0x000000010b2eebcf zig`ReplaceReductionResults(llvm::SDNode*, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::SelectionDAG&, unsigned int, unsigned int) + 191
    frame #5: 0x000000010b2ebcb0 zig`llvm::AArch64TargetLowering::ReplaceNodeResults(llvm::SDNode*, llvm::SmallVectorImpl<llvm::SDValue>&, llvm::SelectionDAG&) const + 4720
    frame #6: 0x000000010616d00e zig`llvm::DAGTypeLegalizer::CustomLowerNode(llvm::SDNode*, llvm::EVT, bool) + 286
    frame #7: 0x000000010619292f zig`llvm::DAGTypeLegalizer::PromoteFloatResult(llvm::SDNode*, unsigned int) + 63
    frame #8: 0x00000001061631d3 zig`llvm::DAGTypeLegalizer::run() + 1939
    frame #9: 0x000000010616fc23 zig`llvm::SelectionDAG::LegalizeTypes() + 1411
    frame #10: 0x0000000106031e5d zig`llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 397
    frame #11: 0x0000000106031632 zig`llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 16594
    frame #12: 0x000000010602b1cc zig`llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 3868
    frame #13: 0x00000001048bf2c1 zig`llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 1329
    frame #14: 0x00000001029fa7a8 zig`llvm::FPPassManager::runOnModule(llvm::Module&) + 8408
    frame #15: 0x00000001029e46e5 zig`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 2245
    frame #16: 0x0000000101df1531 zig`ZigLLVMTargetMachineEmitToFile(targ_machine_ref=0x000000011cacac00, module_ref=0x0000000119183350, error_message=0x00007ff7bfeeb868, is_debug=false, is_small=false, time_report=false, tsan=false, lto=false, asm_filename=0x0000000000000000, bin_filename="~/.cache/zig/o/316a7535932f4451773dbb8a3d05d948/libcompiler_rt.a.o", llvm_ir_filename=0x0000000000000000, bitcode_filename=0x0000000000000000) at zig_llvm.cpp:391:16
    frame #17: 0x0000000100620ebc zig`codegen.llvm.Object.flushModule(self=0x000000011917e830, comp=0x000000011cac0210, prog_node=0x00007ff7bfef1cd0) at llvm.zig:865:34
    frame #18: 0x000000010063df04 zig`link.Elf.flushModule(self=0x000000011cac9000, comp=0x000000011cac0210, prog_node=0x00007ff7bfef1cd0) at Elf.zig:1029:47
    frame #19: 0x000000010061ce81 zig`link.File.flushModule(base=0x000000011cac9000, comp=0x000000011cac0210, prog_node=0x00007ff7bfef1cd0) at link.zig:817:74
    frame #20: 0x00000001003d223d zig`link.File.linkAsArchive(base=0x000000011cac9000, comp=0x000000011cac0210, prog_node=0x00007ff7bfef1cd0) at link.zig:989:33
    frame #21: 0x0000000100187f17 zig`link.File.flush(base=0x000000011cac9000, comp=0x000000011cac0210, prog_node=0x00007ff7bfef1cd0) at link.zig:794:38
    frame #22: 0x0000000100187967 zig`Compilation.flush(comp=0x000000011cac0210, prog_node=0x00007ff7bfef1cd0) at Compilation.zig:2151:24
    frame #23: 0x000000010018adce zig`Compilation.update(comp=0x000000011cac0210, main_progress_node=0x00007ff7bfef1cd0) at Compilation.zig:2115:27
    frame #24: 0x00000001002bddcc zig`Compilation.updateSubCompilation(parent_comp=0x000000011982b610, sub_comp=0x000000011cac0210, misc_task=compiler_rt, prog_node=0x00007ff7bfef1cd0) at Compilation.zig:5298:28
    frame #25: 0x00000001002e5dd1 zig`Compilation.buildOutputFromZig(comp=0x000000011982b610, src_basename=(ptr = "compiler_rt.zig", len = 15), output_mode=Lib, out=0x000000011982b950, misc_task_tag=compiler_rt, prog_node=0x00007ff7bfef1cd0) at Compilation.zig:5394:34
    frame #26: 0x00000001002eab8d zig`Compilation.buildCompilerRtOneShot(comp=0x000000011982b610, output_mode=Lib, out=0x000000011982b950, prog_node=0x00007ff7bfef1cd0) at Compilation.zig:3735:28
    frame #27: 0x000000010018ddb4 zig`Compilation.performAllTheWork(comp=0x000000011982b610, main_progress_node=0x00007ff7bfef1cd0) at Compilation.zig:3076:49
    frame #28: 0x000000010018a0be zig`Compilation.update(comp=0x000000011982b610, main_progress_node=0x00007ff7bfef1cd0) at Compilation.zig:2020:31
    frame #29: 0x00000001001b87ec zig`main.updateModule(comp=0x000000011982b610) at main.zig:3825:24
    frame #30: 0x00000001000310f3 zig`main.buildOutputType(gpa=mem.Allocator @ 0x0000000112e9edf8, arena=mem.Allocator @ 0x00007ff7bfeff1b0, all_args=[][]const u8 @ 0x00007ff7bfef3968, arg_mode=main.ArgMode @ 0x000000011026fd33) at main.zig:3260:17
    frame #31: 0x00000001000043aa zig`main.mainArgs(gpa=mem.Allocator @ 0x0000000112e9edf8, arena=mem.Allocator @ 0x00007ff7bfeff1b0, args=[][]const u8 @ 0x00007ff7bfefec70) at main.zig:268:31
    frame #32: 0x0000000100003a08 zig`main.main at main.zig:212:20
    frame #33: 0x00000001000060ba zig`main [inlined] start.callMain at start.zig:609:37
    frame #34: 0x00000001000060ae zig`main [inlined] start.initEventLoopAndCallMain at start.zig:543:5
    frame #35: 0x00000001000060ae zig`main at start.zig:493:36
    frame #36: 0x000000010000601e zig`main(c_argc=7, c_argv=0x00007ff7bfeff6e8, c_envp=0x00007ff7bfeff728) at start.zig:508:80
    frame #37: 0x00007ff81989641f dyld`start + 1903

[msiedlarek]

I did a little bit of digging. It seems Zig's compiler-rt unconditionally compiles in many routines for 16-bit floats. This also has been previously reported for x86_64 in #7285.

Both fp_armv8 and neon simply pull in half-float support (which is normally optional in Armv8) as a dependency. Entire compiler-rt (and my sample program) can be compiled just fine with -mcpu=generic-fp_armv8-neon+fullfp16.

Now the question is: is Zig supposed to require half-floats on target platforms? LLVM's compiler-rt doesn't, they compile half-float stuff conditionally (COMPILER_RT_HAS_FLOAT16).

[N00byEdge]

Probably relevant: #12090 , #12220 , #10847

[davidgmbb]

Maybe @jacobly0 can help us here since he is familiar with LLVM?

[davidgmbb]

By the way @msiedlarek just to make sure:
The issue here is that @N00byEdge is trying to disable any kind of FPU register use so he can develop kernel software (and not pay the cost of switching FPU registers everytime the kernel is entered/exited. What does this fullfp16 mean? At least for the name it looks like a feature that makes use of FP registers. Thanks a lot for your help.