compiler rt function muldi3 / mulsi3 are incorrectly generated with mutual recursion

[andrewrk]

To reproduce:

zig test -target riscv64-linux-none --override-std-dir ../std ../std/special/compiler_rt/muldi3.zig --output-dir ./
qemu-riscv64 ./test 

output: Segmentation fault (core dumped)

with gdb

qemu-riscv64 -g 9000 ./test 
# in a separate terminal
gdb ./test -ex 'target remote localhost:9000'

Backtrace shows:

#12202 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12203 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12204 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12205 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12206 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12207 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12208 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12209 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12210 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12211 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12212 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12213 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12214 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12215 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12216 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12217 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12218 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12219 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12220 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12221 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12222 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47
#12223 0x00000000004e0004 in compiler_rt.muldi3.__muldsi3 (a=0x0, b=0x0) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:27
#12224 0x00000000004c2f64 in compiler_rt.muldi3.__muldi3 (a=0x0, b=0x38) at /home/lemonboy/code/zig/std/special/compiler_rt/muldi3.zig:47

~It's unclear whether this is an upstream issue or not. The next step is to try to produce a reduction to demonstrate an LLVM bug.~ https://github.com/ziglang/zig/issues/3275#issuecomment-533689407

Reported by @LemonBoy https://github.com/ziglang/zig/pull/3260#pullrequestreview-291024141

[andrewrk]

Reported upstream: https://bugs.llvm.org/show_bug.cgi?id=43388

[andrewrk]

I believe this is related to #2051. Currently when you specify riscv64, this is "baseline" which does not have certain useful features, such as:

• atomics
• 64 bit integer multiplication

even though nearly all riscv boards do have these features. I think zig needs to make it easier to select the more common boards, and more obvious what selections one is making as part of the target.

For example if the target indicated that 64 bit multiplication is available - which it almost certainly is - then it would side-step this issue. Still an issue though.

[andrewrk]

On Linux, clang defaults riscv64 features to "+a,+c,+d,+f,+m,+relax", which side-steps this issue.

[andrewrk]

After 53210b2304990e9b3b0f35f847e13d4ea4ae4ced, this issue is not encountered (however, it should remain open until the bug in compiler-rt is fixed). After that commit RISC-V compiler-rt tests pass and Hello World works both pure-zig and with musl libc.

The next step for RISC-V is behavior tests, which are failing with TODO C ABI panic.

[luismarques]

even though nearly all riscv boards do have these features. I think zig needs to make it easier to select the more common boards, and more obvious what selections one is making as part of the target.

Yes, when targeting Linux the "GC" extensions should be the default (shorthand for IMAFDC). When targeting a bare metal RV64 it arguably makes sense to not assume any extensions by default, although the 64-bit processors are indeed very likely to include the standard ones. In any case, this issue should still be fixed on the compiler-rt side.

[alexrp]

LLVM bug has long since been fixed.

We'll now want to port this over to Zig: https://github.com/llvm/llvm-project/tree/6c331e50e4bfb4158d16ec3fe17ad7bb5c739e9f/compiler-rt/lib/builtins/riscv

[hi7]

I can not reproduce this. When I call: zig test --test-cmd qemu-riscv64 --test-cmd-bin -target riscv64-linux-none lib/compiler_rt/mulXi3_test.zig it shows All 4 tests passed. muldi3/mulsi3 are in mulXi3.zig

[alexrp]

You probably need -mcpu baseline-m to reproduce. The baseline CPU nowadays has features i+m+a+f+d+c.

[hi7]

Thank you for the tip. I still get All 4 tests passed when I add baseline cpu and enter zig test --test-cmd qemu-riscv64 --test-cmd-bin -mcpu baseline-m -target riscv64-linux-none lib/compiler_rt/mulXi3_test.zig.

[alexrp]

Then it's possible that some other change has made this no longer a problem.

You might try disassembling the compiled compiler-rt functions to see what LLVM is doing with them - that might give a clue.

[hi7]

Somehow I'm unable to find a good location to set a breakpoint. Building with zig test --test-no-exec -femit-bin=mulXi3_test -mcpu baseline-m -target riscv64-linux-none lib/compiler_rt/mulXi3_test.zig. strings mulXi3_test | grep mulsi shows some promissing symbols but when I run qemu-riscv64 -g 9000 ./mulXi3_test and gdb ./mulXi3_test -ex 'target remote localhost:9000' in another terminal I find no mulsi. With fo mulsiI getExpression not found`.

[alexrp]

I'm not sure what's up with that, but you could just use objdump on the generated binary to disassemble the related functions.

[hi7]

Ok, I don't see any nefarious things going on in the disassembly. Even though some wild jumping pattern and unconditional jump sequences surprised me...

[alexrp]

Okay, in that case I'm fine with just closing this until we have evidence that there's a problem. Thanks for investigating!